ByPays
A buy-now-pay-later dashboard that answers one question first: what do I owe, where, and when.
- Type
- Fintech dashboard
- Role
- UX Designer
- Timeline
- 6 weeks, concept to dashboard
- Tools
- Figma, Figma Prototyping
the answer, before the details
amber means this week
answers the v1 question
Overview
ByPays is a buy-now-pay-later card: one card, several installment plans running at once across different stores. I designed the account dashboard a cardholder opens to answer one recurring question, what do I owe, where, and when, without piecing it together from separate store receipts.
Problem
BNPL debt is split by design: a laptop in 6 payments at one store, a jacket in 4 at another, each on its own schedule. The BNPL apps I compared show that one purchase at a time, so the question a cardholder actually has, what do I owe across everything right now, takes mental math the app never does for them.
Process
- 01I opened the dashboard on the answer: the total owed across every plan, in one large number, with the next payment, its store, its date, and a Pay button directly under it. My first draft spread that across four equal stat cards.
- 02I gave 'due soon' its own color. Amber marks a payment due within a week, on the dashboard and in the plan schedule, and nothing else on the page uses it.
- 03I merged purchases and plans into one list. In v1, a purchase sat in Recent Transactions and its plan sat in a separate Active Payment Plans card, and the cardholder had to connect them by store name. Now each purchase row carries its own plan: payments made, what's left, the next date.
- 04I drew plan progress as one segment per payment instead of a percentage bar, so you can count paid payments at a glance.
- 05I answered the open question from v1 with a pay sheet. The default pays the next installment; everything due this month and paying a plan off are one tap away, each with its amount shown.
- 06I cut the three value cards (Flexible Payments, 0% Interest, Earn Rewards) from the bottom of the dashboard. They were marketing inside a tool, and the only claim worth keeping, no interest, now sits under the total.
Purchases and plans, twice
v1: two lists, matched by eye
v2: each purchase carries its plan
Design system
A light, cool ground (#f6f7f8) with white panels, because people open this to check numbers, often during the day at a desk. Teal (#0a8f84) is the only action color and the color of progress: paid segments, Pay buttons. Amber (#b45309) means due within a week and appears nowhere else. The ByPays card is plain black with a teal stripe instead of v1's purple gradient, so teal and amber stay the only saturated colors, on actions and due dates. Type is Albert Sans with tabular figures; corners are 10 to 16px rounded rectangles.
- Ground#f6f7f8
- Ink#14161a
- Teal, act#0a8f84
- Amber, due soon#b45309
- Line#e3e6ea
Outcome
I designed and prototyped the account dashboard as a light web app: the owed summary with the next payment, available credit, the merged purchases list, spending by month, one plan opened to its full schedule, and the pay sheet, with the v1 layout kept for comparison. Before build, I'd add the filter and plans-first sort described below, then test the pay sheet with cardholders who have four or more plans, to see whether the default still matches what they came to pay.
Reflection
Merging the two lists fixed the problem I flagged in v1, and it made a new one. The purchases list now grows with every coffee bought on the card, and the plans, the part people worry about, get pushed down as it fills. For this mock, with three plans and two small purchases, it reads well. At thirty purchases a month it won't, and I haven't designed the filter or the 'plans first' sort that would fix it. That's the next thing I'd build, before the pay-sheet test.