Creating a balance and payments experience for a membership-based fintech product.
--
Overview
Our fintech product, Quin, needed a payment system for members. Offering two different membership types meant different experiences would be required.
Role
Design Lead
Team
Product Manager
Project Coordinator
Dev Lead
Multiple Developers
Constraints & Considerations
There were two types of membership as Quin transitioned to a newer, more financially-inclusive model. There were classic members and lite members. Lite members received access to Quin’s flagship product, an unemployment benefit called Lifestyle Protection, (later renamed Layoff Protection.) Classic members were approved for a credit card along with Lifestyle Protection. Each type of membership necessitated a different experience. Quin’s mission is to help members create financial security to build real generational wealth. Thus, those members with a Quin credit card were also encouraged to pay their entire balance monthly to keep credit utilization low and work to increase their credit score.
Goals
All of Quin’s members would need to be able to:
1. View their current membership (monthly) balance.
2. Pay their membership fees.
3. Access and enable autopay for membership.
In addition, Quin’s classic users would need to be able to:
1. View their credit card balance.
2. Pay their credit card balance.
3. Make a minimum credit card payment.
4. Make a custom, partial payment of more than the minimum and less than the full balance.
Approach
Like every aspect of the Quin user experience, we set out to make users successful one step at a time, balancing business goals and user autonomy. Information and actions would be sorted by priority, and each new action and concept would need to be distinct.
For the majority of Quin members, this would be a simple display of their monthly membership balance and a payment pathway. For classic members, we would prioritize users paying their entire credit card balance and allow them to make smaller payments in a low-friction manner.
I explored several possible solutions and ultimately designed a single-screen solution, nesting actions that were considered low priority. There was a little pushback, as some stakeholders felt more comfortable with a UI similar to those of big bank credit card payment systems. However, after some discussion and assurance through examples of modern, user-friendly payment systems, we decided to implement the design.
Compliance Feedback & Revision
As autopay is a feature that requires an agreement, we couldn’t simply turn it on for users with a toggle. We would need to take them to the agreement to review and sign off on. Though solutions were suggested from across teams, I used a pattern established in different areas of the app experience. The toggle would remain in the “high priority” component slot at the top of the balance & payments screen (as well as the home screen,) and a drawer tab would pop up, containing the agreement for the user to confirm. Time constraints meant considering some UX experience tradeoffs. Ultimately we decided the toggle experience would be a fast follow.
Outcome
The result was a strategically low-friction payment experience that empowered and benefited users. Our biggest accomplishment was that month-to-month users consistently made membership payments on time. Though we had a long-term strategy for obtaining feedback on the payment experience, it wasn’t implemented before Quin ultimately reformed due to a change in partnership. Nevertheless, there was no negative feedback from users concerning payments, nor were there payment experience issues that needed support.
