- Date: September 30, 2026
The Problem
FlexUp needed a Billing section that could hold two contradictory promises at once: total flexibility (six plan tiers, usage-based extras, no pre-purchased quotas) and total simplicity (“you don’t have to worry about which plan you need”). The founder’s brief was explicit: the design had to feel fair and transparent, never punitive, even when it was delivering bad news like an overage charge or a payment failure.
The ticket arrived with a business spec, a reference spreadsheet, and a meeting transcript, but no existing pattern to follow. Six plan tiers, two billing modes (Auto-optimise vs. Manual control), an optional spend cap, and a full set of confirmation and gating states all had to be designed from scratch.
Process
I worked from the ticket, the backend spec, and a stakeholder meeting transcript to extract the actual business rules before touching any screen: usage is billed on peak count for seats and cumulative totals for orders/storage, extras are always calculated automatically and never pre-purchased, upgrades apply instantly and downgrades take effect the following month.
Every screen went through dozens of rounds of stakeholder review in Figma, with a clickable prototype covering each state, modals, toasts, and live calculations, so stakeholders could interact with the real logic rather than just look at static frames.
Design decisions were validated against a second stakeholder meeting where the dev team independently reviewed the Payment Terms screens and confirmed the structure, credit-line breakdown, and gating logic matched their build plan, catching only a terminology mismatch (“payment method” vs. “payment term”) before handoff.
Key Design Decisions
Auto vs. Manual had to be a real behavioral difference, not a relabeled toggle. Early builds showed the same “Switch to Scale” recommendation banner regardless of mode. I corrected this so Auto-optimise silently performs the plan switch and reports it after the fact (“We moved you to Scale — you’re saving €100/month,” no buttons), while Manual control surfaces the same opportunity as a decision the user must actively confirm. The distinction matters because the ticket’s core promise, hands-off optimization, was previously undermined by the two modes behaving identically.
The spend cap needed to protect without punishing. Rather than a hard block with no explanation, hitting a cap or plan limit surfaces a paused state with three equally weighted ways forward (upgrade, raise the cap, add extras for this month), reframing a limit as a safety net instead of a wall.
Scope boundaries had to be renegotiated mid-project. A later stakeholder review determined that full member management didn’t belong inside Billing at all. The Members tab was reworked from an editable table with add/remove actions into a read-only seat-count summary (included, extra-paid, FlexUp staff), with a clear hand-off link to the account’s actual Team management area, removing duplicate ownership of the same data in two places.
Financial logic surfaced real bugs before they shipped. Rebuilding the prototype with working math (rather than static mockups) caught a real inconsistency: a demo “you’d save money by upgrading” scenario assumed a target plan would have zero extras, but the underlying usage numbers actually exceeded that plan’s own limits too. Correcting the mock data preserved the design’s core promise: never show a savings number that wouldn’t hold up in production.
Payment Terms had to gracefully handle an incomplete legal state. For accounts without a signed charter, only one payment method is legally available. Rather than hiding the flexible payment options entirely, the mix editor shows a single disabled row with locked controls and a persistent explanation of what unlocks them, so the constraint teaches the user what’s coming rather than just blocking them.
Outcome
The ticket produced a complete, interactive specification covering plan selection and comparison, usage and extras tracking, both billing modes, spend caps, member seat summaries, Stripe-based payment method management (redirect flow, saved cards, default switching), account freeze and grace-period states for non-payment, and a new Payment Terms and Credit Lines section for the platform’s separate credit-based payment rail. Every interactive state, not just the static screens, was tested and confirmed working before handoff, and the design was independently validated by the engineering team’s own review of the same requirements.
What I'd Take Forward
Building a working prototype instead of static mockups surfaced real logic errors that a purely visual review would have missed, and it made stakeholder conversations concrete: instead of describing what “Auto-optimise” should do, I could show it happening. The project also reinforced that “simple” and “transparent” are often in tension with each other in fintech UX, and resolving that tension usually means separating what the system decides automatically from what it merely recommends, and being explicit about which is which at every step.