People abandon signup at the document step
Not because the form is ugly — because it asks for paperwork they don't have on them. The fix is sequencing, not styling.
Fintech product design
Financial products fail in the gaps between steps.
We design payments, banking and lending products for teams who can't just remove the awkward step. Identity checks, disclosures and limits stay. What changes is their order, their honesty and how a person recovers when something is declined.
Talk about your flow →
What's different about designing for money
In most software, a confusing screen wastes a minute. In a financial product it makes someone wonder whether their money is safe — and that suspicion doesn't get repaired by the next screen. So the work is less about visual polish and more about certainty: what just happened, what happens next, when it will be done, and what to do if it isn't.
The second difference is that you can't design your way out of an obligation. Identity verification, source-of-funds questions and consent screens exist for reasons that outlive any redesign. Teams get stuck because they treat that as a dead end. It isn't — it's a sequencing problem, and sequencing is design work.
- Who we work with
- Payments processors, wallets and neobanks, lenders, insurtech teams and finance tooling for businesses — usually a product lead with a compliance colleague in the room.
- Where we usually start
- The single flow that carries the most abandoned value: account opening, first transfer, or the application form people quit halfway through.
- What we don't do
- We don't write your regulatory policy, run your ledger or promise conversion numbers before we've watched anyone use the product.
Problems we're usually called about
Six failures we see in nearly every fintech audit.
Compliance arrives at sign-off
A flow gets designed, reviewed, then sent back because a disclosure or consent step was never in the wireframes. Involving compliance in week one costs a meeting and saves a rebuild.
Mobile and desktop have quietly diverged
Two teams shipped the same flow twice. Field validation, error copy and limits now disagree, and support absorbs the difference.
The dashboard answers questions nobody asked
Balance and volume charts on top; the thing a merchant actually opens the app for — did today's payout land — three taps down.
Error states are an afterthought
Declined cards, failed verification, blocked transfers and hold periods carry the most emotional weight in a financial product and usually get the least design attention.
Nobody agrees what 'better' means
Without a named metric before design starts, a redesign gets judged on taste in a stakeholder review and everyone loses.
If several of those sound familiar, a UX research and audit engagement is usually the cheapest way to find out which one is costing you the most.
Capabilities
What we design inside a fintech product.
Onboarding and KYC flow design
Progressive identity capture, resumable verification, document upload that survives a bad camera and a worse connection, and honest status communication while a check is pending.
Merchant and account dashboards
Payout visibility, reconciliation views, dispute handling and limits explained in plain language rather than API terminology.
Money movement flows
Transfers, payment requests, recurring collection and refunds — designed with confirmation, reversibility and failure states specified before the happy path is polished.
Lending and application journeys
Eligibility, affordability, offer comparison and post-approval servicing, including what a declined applicant sees and what they can do next.
Compliance-aware interface writing
Disclosures, consents and fee explanations written to be read, then routed through your compliance review instead of pasted in at the end.
Design systems for regulated products
Components that treat pending, restricted, verified and blocked as real states, with tokens and accessibility baked in so front-end teams stop re-deciding.
Deliverables
What lands in your repo and your drive.
Written into the proposal before we start, so there's no argument later about what "design" included.
- Annotated flow maps for signup, verification and first transaction, including every failure branch
- Research findings with session recordings and a ranked list of where people actually stall
- Interactive prototypes for the flows we're testing, on the devices your customers use
- Production-ready UI for the redesigned surfaces, implemented as components
- State inventory: pending, partial, restricted, declined, expired, blocked
- Interface copy drafts flagged for compliance review
- A measurement plan naming the metric, its current baseline and how it will be read after launch
How the engagement runs
Five phases, and the one that people skip.
Phase three is the one most teams skip, and it's the one that decides whether the redesign is allowed to ship.
01
Frame the money question
One session with product, compliance and support to agree what the product is failing at and which number would move if we fixed it. We leave with a baseline, not a mood board.
02
Watch real people transact
Eight to twelve customers or merchants, on their own devices, doing the task for real. We record where they stop, what they go looking for, and what they say to themselves while waiting.
03
Separate mandated from inherited
Every step gets a source: regulation, internal policy, or 'it's always been there'. Only the third category is free to delete, and it's usually bigger than anyone expects.
04
Redesign the sequence
Fast, memory-answerable questions first. Verification on a resumable track with a real handoff. Waiting states that explain themselves. Then we prototype it.
05
Test, ship, measure
A second round of testing on the prototype, then implementation in increments so you can read the metric between releases instead of after a big-bang launch.
Compliance, in practice
We treat the rules as inputs, not obstacles.
Mandated steps stay
Identity verification, consent capture and record-keeping remain intact. We ask for the source of each requirement so we design against the real obligation rather than a team's memory of it.
Order is negotiable
Most of the abandonment we find comes from asking for the hardest thing first. Moving verification later — with a limited-capability account in the meantime — usually satisfies both compliance and the customer.
Copy goes through review
We draft plain-language disclosures and mark anything that makes a claim, then hand it to your reviewers. Nothing we write bypasses your sign-off process.
Where this applies
Fintech is six different products.
Payments and acquiring
Merchant signup, settlement visibility, dispute and chargeback handling.
Digital banking and wallets
Account opening, card controls, limits, statements and dormancy re-engagement.
Lending and BNPL
Application journeys, affordability, servicing and arrears communication.
Wealth and savings
Risk profiling, goal setting, portfolio views and honest performance display.
Insurtech
Quote flows, claims submission and status tracking people can follow without calling.
B2B finance and treasury
Approval chains, multi-user permissions, bulk operations and audit trails.
Fintech work
We rebuilt account opening around the two minutes that actually mattered.
Nova Pay
Fintech · 2025 · Research, Product design, Design system
Nova Pay was signing up small merchants at scale, but four in ten never finished opening an account. The team assumed it was a compliance problem. It wasn't.
We split the flow in two. Everything a merchant could answer from memory came first, in under two minutes, and unlocked a limited sandbox account immediately. Verification moved to a resumable track with SMS handoff, so a merchant could photograph a document that evening and pick up exactly where they left off.
- 47%
- Drop in onboarding abandonment
- 1:52
- Median time to first account
- 24
- Components in the shipped system
Services behind this work
A fintech engagement usually combines three of these.
FAQs
What fintech teams ask us first.
Anything not covered here, put it in the form — a real person answers, usually within two working days.
- Can you design an onboarding flow without weakening our KYC obligations?
- Yes — the flow changes, the checks don't. We ask your compliance lead which steps are mandated and by whom, then resequence the rest so people answer from memory first and upload documents later, on a resumable track.
- Do we need to give you production data or customer access?
- No production data. For research we need access to a handful of real users or a recruitment budget to reach them, plus a staging environment. Anonymised funnel numbers are enough for the analytics side.
- How long does a payments onboarding rebuild take?
- A focused flow — signup through first successful action — usually runs six to ten weeks including two rounds of testing, shipped in increments. Wider platform work is scoped in phases rather than one long project.
- Do you build the front end or only hand over designs?
- We hand over implemented components for the surfaces we redesign, which is why our handovers don't need redlines. Backend, ledger and integration work stays with your engineers.
- Can you work with our regulator-facing copy?
- We draft the interface copy and flag anything that makes a claim, then route it through your compliance review before it ships. We don't sign off legal wording ourselves.
- What if our problem is churn after onboarding, not signup?
- Then we start with a UX audit of the first month rather than the first session. Activation, dormancy and re-engagement need different instrumentation, and we'd rather find that out in week one than week six.
Related reading
Losing applicants at the verification step?
Send us the flow and the drop-off number. We'll tell you where we'd look first — no charge for that part.
Start a project