Overview
Allowing Users to change the payment date for subscriptions with recurring payments. The payment date is a subscription-specific attribute, based on the date of the subscription's initial payment date and the billing cycle of the plan. The Payment Date cannot be changed or predefined. If a UoU (user of the user) purchases a monthly plan on 13th March, their next payment date will be 13th April.
The Problem
Today, the payment date of a subscription is defined according to the initial purchase date. Users want to have the ability to adjust the recurring payment date as fit for their customer and their business.
The project was designed as part of my work at Wix (2023)
Incentives for Change Payment Date
-
Align payment date across all active subscriptions
-
Change payment date according to UoU preference
-
Align the payment date with the order supply date
-
Align the payment date with the date of service provision
Solution
Enabling the user to change the payment date on a recurring subscription.
Main Goal and KPI
The Goal
Providing flexibility for users in the management of their subscriptions and customers.
Main KPIs
-
Usage of “Change payment Date”
-
Approval rate increase among users who changed payment date
Research
When a user changes their payment date, the duration of the billing cycle is either shortened or extended. However, the user paid in advance for exactly one full cycle. In order to resolve the amount paid with the service provided - either the subscription duration or the payment amount needs to be adjusted (proration).
Competitor Analysis // Competitor A
-
Edit Billing Date - Changes the billing date permanently for all future billing cycles.
-
Proration is optional, the user can select not to apply proration.
-
No option to adjust subscription duration as an alternative for proration.
-
If not prorated, the user can create credits and charges manually too.
-
If a charge is raised - The user can charge immediately or add to the next renewal.
-
If a credit is raised - it is automatically applied to the next invoice (cannot be postponed).
-
Users can apply a billing date to a plan (Calendar Billing)
-
Users can mass-update billing dates
Competitor Analysis // Competitor B
-
Changes the billing date permanently for all future billing cycles.
-
The action does not create charges of credits, or affect the subscription term.
-
Users can issue credits and charges manually.
-
Users can adjust the subscription term manually.
-
Option to preset billing date - at the account level.
-
No Bulk update option.
Low Fidelity
Subscriptions on a weekly billing cycle differ from monthly or annual billing cycles when changing a payment date. The difference is that in a weekly billing cycle, the user requests to change the payment day, but in a monthly or yearly billing cycle, the user requests to change the payment date (or- the day of the month). My solution was to create different entry points to match them to the billing cycles.
In a subscription with a weekly billing cycle, the user must select the new payment day (from a dropdown with all days of the week except the current payment day).
Usability Tests
When I handled choosing a payment date for a monthly or annual billing cycle, I chose to use a date picker that only displayed the months with days that could be the payment date. But then, I was worried that in cases where the desired day could be both in the current month and in the next month, the user might miss one of them and choose to advance the payment date when he intended to postpone it.
To solve this concern, I made another version that showed two drop-down menus, one for selecting the day of the month and the other for choosing the month. In addition, next to the options, I indicated whether the selected choice would precede or postpone the next payment.
A date picker that displayed months with days that could be the new payment date
Version A
Two drop-down menus, one for selecting the day of the month and the other for choosing the month
Version B
User Interface
After I solved the first step where the user chooses the date (or day) of the upcoming payment, and I solved the second step where the user chooses how he wants to treat the next payment: to include the price increase or credit, or not change the price. In the third step, I presented a short and clear summary before he approved the action.
After confirmation, the changes are updated in the field of the next payment on the overview screen with a success message confirming that the operation was successful.
CHANGE
PAYMENT DATE
WIX
🦺
Oops!
I'm working on the mobile version in order to avoid this awkward situation.
I'd love if you could access my portfolio from your computer's browser.
Would you like to chat? Let's talk.
Role
UX Designer
Team
Product manager, UX, UXW, FED, BED
Tools
Figjam, Figma
Timeline
2 months, 2023
Proration
The price for the next payment is calculated according to the actual days of service provided, and credits or charges are raised.
How and when is the charge/credit applied?
An extra charge will be added to the next payment date.
A credit will be applied to the next payment date.
I decided to perform usability tests on both versions and see the behavior of users in each of them. Version A won. The five users I tested claimed unequivocally that the calendar view was much more intuitive. In addition, I understood from them that the consideration of whether to advance or postpone the payment date is just one of many other considerations they take into account. These considerations include the local payday, shipping days, and more.