Fintech Design Is Solving the Wrong Trust Problem
Akinkunmi Oyehan6 min read·Just now--
Open any major Nigerian fintech app. The onboarding is clean. The typography is confident. The dashboard loads fast and the balance is prominent and the primary actions are easy to find. From a design standpoint, the surface is good. Most of them have solved the presentation layer.
Now try using one when something goes wrong.
The moment the design stops working
The transfer that processes and doesn’t arrive. The deduction that shows up without a corresponding transaction. The verification loop that tells you to try again without telling you what to try differently. These are not exotic failure scenarios — anyone who moves money with regularity has been here, usually at a moment that already felt urgent. And in that moment, you find out what the product actually thinks of you.
Most Nigerian fintech products, in that moment, go quiet. The error message is generic. The next step is unclear. The status of your money — the one thing you came to know — is the one thing the interface won’t commit to. You’re left reading the screen for information it doesn’t have, because nobody designed that screen with the same attention that went into the onboarding.
This is the trust problem. Not the branding. Not the colour system. Not whether the empty state has a nice illustration. The trust problem is what happens to a user at 11pm when a transaction fails and the product has nothing useful to say.
Credibility is a launch problem. Trust is a forever problem.
There’s a distinction worth making precisely because it gets collapsed so often. Credibility is what you signal before someone has meaningful experience with your product. It’s the first impression — visual, tonal, structural. It says: “we are a real company that has thought about this.” Trust is what accumulates over time through repeated interactions, including the ones that go wrong.
These are different design problems. Credibility responds to the surface. A cleaner interface, a more consistent type system, a more polished onboarding — these genuinely move credibility. Trust doesn’t respond to the surface at all. It responds to behaviour. Whether the product told you the truth when a transaction failed. Whether it explained the fee before or after it was deducted. Whether the support flow treated you like someone with a real problem or a ticket number to be processed.
The Nigerian fintech wave understood the credibility problem clearly and solved it quickly. The challenger apps arrived looking sharper than the legacy banks they were displacing, and that contrast did genuine work. People chose them partly because they looked like something the old system wasn’t. The visual investment had a real return.
What followed was a decade of design effort that kept solving the same problem. Better illustration systems. Tighter component libraries. More sophisticated animation. More considered colour systems. All of it aimed at the same target: the first impression. The moment before the user had done anything that actually mattered.
The trust problem went mostly unaddressed because it didn’t have a before/after screenshot. It didn’t have a launch moment. It lived in the aggregate of small decisions — what an error message said, how a loading state communicated uncertainty, whether a receipt told the full story of a transaction — and those decisions are hard to prioritise in a roadmap because the cost of getting them wrong is diffuse and the benefit of getting them right is invisible until you look at retention data six months later.
What the design brief looks like when trust is the goal
Working on fintech products at Nomba, the conversation I kept trying to have was about designing for the 10%. The happy path — the user who opens the app, does the thing they came to do, and closes it — is well served. The experience is clean and the flows are logical and the visual feedback is timely. That 90% of sessions is in good shape.
The 10% is the sessions where something doesn’t work. The transaction that stalls. The account that gets flagged. The verification that fails without explanation. In consumer fintech, where the product is handling real money, that 10% is not a rounding error. It is the test. It is the moment where the user decides — consciously or not — whether they actually trust this product with their financial life.
Designing for that 10% requires a different brief. Not “how do we make this flow faster” but “what does this user need to know right now, and are we giving it to them?” Not “does this error state look clean” but “does it tell the user what happened, whether their money is safe, and what to do next?” These questions have answers that are harder to fit in a sprint and harder to evaluate in a design review, because they don’t look like much on a Figma frame. They look like copy. They look like logic. They look, to someone who isn’t asking the right questions, like details.
At Fundall Business, the users were business owners running actual payroll. When a transaction failed in that context, the stakes were not abstract. A missed supplier payment has a supplier on the other end. A failed payroll run has employees on the other end. The product had a clean, well-designed dashboard for the happy path. The failure states were generic — “transaction failed, please try again” — without any of the information a business owner needs to know whether to retry immediately, wait, call support, or escalate. The design had been thorough about what to do when everything works. It had not been thorough about what to do when it doesn’t.
Who gets the error screen
The structural reason this keeps happening is about where design attention gets concentrated. Error states, empty states, and edge cases go through a product review in which the primary question is usually “is this technically correct” rather than “is this actually useful to someone in distress.” They get reviewed after the happy path is approved, in the time that’s left over, by a team that’s already spent its energy on the primary flows.
Nobody puts an error message in their portfolio. Nobody presents the failed transaction screen in a case study. These artefacts don’t make the work that represents you, so they don’t get the investment that the work representing you gets. This is a structural problem, not a personal one. The incentives of how design work is evaluated point away from exactly the screens where trust is built or broken.
The result is products that look excellent in demos and feel unreliable in real use. Not unreliable in the sense of crashing — the technology mostly works. Unreliable in the sense of not communicating clearly enough that it’s working. Not giving users the information they need to feel safe. Treating moments of failure as technical events rather than human ones.
The 11pm moment
There’s a user I keep designing for, even when nobody has put them in the brief. They’re moving money at 11pm. Not because they chose to, but because something came up. A supplier needs payment tonight. A family member needs a transfer before morning. The stakes feel large and the hour is inconvenient and the product is the thing standing between them and resolution.
In that moment, the gradient in the header doesn’t matter. The microanimation on the button doesn’t matter. The illustration on the empty state doesn’t matter. What matters is whether the product tells the truth — whether it gives the user accurate information about what’s happening with their money, in plain language, at the moment they need it most.
Most Nigerian fintech products are not designed for that user. They’re designed for the user in the demo, the one doing the thing they’re supposed to do under ideal conditions. That user is a fiction. Real users do unexpected things, at inconvenient hours, with higher stakes than your test account simulated.
The credibility problem in this market is solved. The apps look professional. The category is established. Users know what a legitimate product looks like. Competing on the surface is a diminishing return.
What’s left — and what the best products in this space will be defined by over the next decade — is the work of designing for the moments when things go wrong and the user is already stressed. That work is unglamorous. It doesn’t show well in a portfolio. It is also the only work that actually builds trust.
The 11pm moment deserves a senior designer. It almost never gets one.
