In brief
Almost every fintech founder who opens a laptop in front of us says a version of the same sentence: we want it to feel trustworthy. What follows is usually a dashboard — a balance, a graph, a transaction list, four buttons competing for the same corner — and no answer to the question the design actually turns on.
The question is not what the product does. It is what the product is for, at the moment somebody opens it. A savings app and a trading app both show a number going up or down. They are not solving the same design problem, and an interface that treats them as though they are will feel wrong in a way that no amount of colour correction fixes.
Checklist
The order the checklist runs in
Five checks we run before any screen is designed. The order matters more than the list: each one narrows what the next is allowed to decide.
Tick the checks your team has already run. Your answers stay on this page; nothing is sent or stored.
None of this is exotic. It is a different order of operations from the one most founders arrive with, which usually begins at step three of a visual design process and works outward.
10 items, 7 of them essential. Tick the checks your team has already run.
Why start with the emotional job, not the feature list?
“Let users check their balance” is a functional job. “Let a first-time investor feel they are not about to lose their savings” is an emotional one. The first tells a designer what to build. The second tells them what to subtract, which is the harder and more valuable instruction.
Write the emotional job as one sentence before anything is drawn. It should be specific enough that it rules something out. If it could be printed under any fintech product in the market, it is not yet doing any work, and every later argument about layout will be settled by whoever is most senior in the room rather than by the brief.
What should you audit before you look at colour?
Founders bring brand guidelines before they bring a single real data scenario. That is the wrong order. Show us what the screen looks like when a transaction fails. When a balance is zero. When a merchant name runs to forty characters, or a currency needs three decimal places, or a transfer sits pending for two days.
Those states are the product. A successful transaction alone does not show whether the product handles uncertainty or recovery well. A palette applied over unexamined data states produces a screen that looks composed in a slide and falls apart in production.
What are you willing to leave off the screen?
Fintech teams default to more information, on the theory that transparency equals trust. It does not. Past a point, volume reads as risk: a person who cannot tell which number matters assumes the important one is being hidden.
The interfaces that feel most trustworthy are usually the ones that have decided, explicitly, what they are not going to show at that moment. That is a decision with an owner and a cost — somebody wanted each of those elements — which is why it has to be made before design starts rather than negotiated per screen. The same restraint problem shows up in storefronts that interrupt a purchase, where more reassurance often converts worse than less.
Which moment should you design for first?
Onboarding gets most of the design attention because it is the easiest thing to demo. But the screen a user actually remembers is the one they opened at eleven at night because a payment had not arrived.
Design that screen first. What does it say? How quickly does it distinguish “processing” from “failed” from “we do not know yet”? Is there a next action, or only a phone number? A product that handles the moment of doubt well earns more trust than one with a beautiful first run, because that is the moment the user is deciding whether the company is competent.
How do you tell a design decision from decoration?
If a choice — a gradient, an animation, a card layout — cannot be traced back to an outcome such as activation, retention or reduced support contacts, it is decoration. Decoration is not automatically wrong; it is simply unbudgeted, and it should be recognised as such rather than defended as strategy.
The test is a sentence: this exists so that this becomes easier or clearer. Where the sentence cannot be finished, the element is a candidate for removal. Applied consistently, this is what separates a product design engagement from a reskin. For how the same thinking plays out across a full build, see our piece on fintech product design in India.
What evidence makes the checklist ready to build?
Run it with product, design, engineering and support. Add the compliance owner wherever the journey includes disclosures or consent. Mark each item ready, blocked or untested; attach evidence and name the person resolving each gap.
- Emotional job: one sentence tied to a user task. Example: help a sender understand whether money has left their account. Validate that understanding with a prototype task.
- Data states: a state sheet covering loading, empty, pending, failed, completed, reversed and unavailable data. Each state needs the source of truth, approved copy, next action and recovery owner.
- Restraint: an agreed information hierarchy. Keep the amount, recipient, fees and material consequences available before commitment; simplifying a screen must not hide information needed for a decision.
- Moment of doubt: a tested recovery flow. A pending transfer should explain what is known, when status was last checked and how to get help. Offer retry only when engineering can establish that it will not duplicate a payment.
- Outcome: a baseline and a measurement plan. Track successful completion alongside duplicate attempts, errors and support contacts. A faster flow that increases mistakes is not a win.
Which accessibility checks belong before sign-off?
Test the critical flow with a keyboard, a screen reader and enlarged text. Use words as well as colour for transaction status, keep focus visible and associate errors with their fields. Check that a status update is announced without forcing users to search the screen.
W3C's WCAG 2.2 error-prevention guidance describes alternatives for consequential submissions: reversal, input checking with correction, or review and confirmation before submission. Its status-message guidance explains how updates can be available to assistive technology without moving focus. Use these as design acceptance criteria; these checks alone do not establish full WCAG conformance.
This is the review framework we run before design begins. It is a set of questions, not findings about any particular product — the answers differ for every company that runs it.
FAQ
Does this replace a design system?
No. A design system answers how components behave once the product’s job is settled. This checklist runs earlier, while that job is still a sentence somebody has to write down. Starting a system before the job is agreed usually produces a tidy library of screens that solve the wrong problem.
We already have brand guidelines. Is that enough to brief a designer?
Brand guidelines describe how the product should look and sound. They do not describe what a user is trying to decide, or what the screen must show when a payment fails. Both are needed; the guidelines are rarely the constraint that shapes the interface.
How long does this take before design starts?
It is usually a short exercise, not a project. The cost is not time but candour: naming one emotional job means declining others, and deciding what not to show means disagreeing with somebody who wants it shown.