Creating a balance and payments experience for a membership-based fintech product.

Billy Rose (he/him)
3 min readMar 8, 2023
Digital 3d illustration of different payment system UI components floating on a lavender background.

Back to Billy’s portfolio


Our fintech product, Quin, needed a payment system for members. Offering two different membership types meant different experiences would be required.

Multiple phones with different payment screens showing features of the payments and balances system.
Phone screens showing various options from the Balance & Payments UI


Design Lead


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.

Users with digital (and physical) Quin credit cards needed a more in-depth payment and balance experience.


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.


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.

Different payment options for different users. From L to R: payment UI for Quin Lite users, nested options for Quin Classic users, expanded options for Quin Classic users.

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.


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.



Billy Rose (he/him)

UX Designer in the garden, on the MPC, or eating potatoes in the Sonoran Desert.