Designing for Trust in Fintech Products
On a peer-to-peer payments app we built for a client entering the remittance space, our first version of the send-money confirmation screen showed the amount, the recipient, and a single 'Confirm' button. In usability testing, three out of eight participants hesitated for over ten seconds before tapping it, not because they were confused about the flow, but because the screen gave them nothing to double-check against their own intent.
We rebuilt it to explicitly restate the exchange rate, the fee, and the total the recipient would receive in their local currency, each on its own line, with the fee never bundled invisibly into the rate. Hesitation on that screen dropped sharply in the next round of testing. In fintech, ambiguity reads as risk, and risk reads as 'maybe this app is stealing from me,' even when nothing is actually wrong.
We're also deliberate about what feels 'boring' by design. Early mockups used a bright, energetic palette to match the client's marketing brand, but during testing, users associated the brighter screens with the marketing site and the calmer, more restrained transaction screens with 'the part where my money actually moves.' We ended up with two visual registers in one app: expressive for marketing and onboarding, restrained and almost clinical for anything involving a real transaction.
Error states got the same scrutiny. A failed transfer that just says 'Something went wrong, try again' is the single fastest way to lose a fintech user's trust, because the user's mental model jumps straight to 'did my money disappear.' We now require every payment-flow error to state explicitly whether money moved, whether it will be retried, and what to do if it doesn't resolve, even if that means a longer error message than our style guide would normally allow.
Trust in these products isn't built by one reassuring screen, it's built by the absence of a single moment where the user has to guess. We treat every unresolved 'what happens next' question in a transaction flow as a launch blocker, not a nice-to-have.
