What I Check First in a Fintech UX Audit — A Senior Designer's Field Notes
Anyone can list a hundred things wrong with an app. The skill is knowing which three to look at first — and which ninety-seven to ignore.
Strahil Hadzhiev
AUTHOR
The tell of a junior audit: it tries to audit everything
Hand a fintech app to a junior designer and ask for an audit, and here's what you get back: forty screens, three hundred redlines, every contrast ratio and corner radius flagged, and no idea what to fix first. It looks thorough. It's actually useless. A wall of findings with no priority isn't an audit — it's noise with screenshots.
Twenty years in, my audits have gotten shorter, not longer. Because the real skill was never finding problems. In a complex money app you can always find problems; they're infinite and mostly trivial. The skill is knowing which handful actually cost the business users and money, and having the discipline to ignore the rest. A senior audit isn't a longer list. It's a much shorter one, aimed at the right place.
So the first thing I do is refuse to start with a heuristics checklist. That's the classic trap — opening a generic UX checklist and marching through every screen grading it against rules. Do that and you're just cataloguing what looks wrong to you, which is often nothing like what's actually hurting. I start somewhere else entirely: with the business goals and the user data. Before I judge a single screen, I want to know what this product is trying to move — activation, KYC completion, first-transaction success — and where the numbers say people are actually falling out. Audit what's impacting performance, not what offends your taste. Your aesthetic opinion about a button is worth very little. The drop-off point in the funnel is worth everything.
And I go straight to where trust is won or lost, which in a financial product is almost always the same three flows: onboarding and identity verification, funding or linking an account, and the first real transaction. Those are the moments that decide whether someone becomes a customer or a ghost. Ninety percent of the app's screens can be perfectly fine and it won't matter if those three flows leak. So I don't spread my attention evenly — I pour it into the two or three places that carry the whole relationship, and I deliberately, unapologetically skim the rest. Knowing what not to audit is the most senior skill there is.
That's the mindset. Here's what I'm actually looking at once I'm in those flows.
the trust-sensitive moments I check first
When I open a money app to audit it, I'm not running a generic usability pass. Financial products have their own specific failure points — trust-sensitive, regulation-heavy, money-in-motion — and I go straight for them. These are the field notes, the things I check first, more or less in order.
Money-state clarity. The very first thing: can the user always tell what their money is doing? Pending, posted, processing, failed, on its way — is the state of every dollar obvious at a glance? This is where a shocking number of fintech apps quietly fail. A payment that just... disappears into an ambiguous limbo with no status is one of the most trust-destroying things a money app can do. If I can't immediately tell where my money is and what's happening to it, nothing else in the audit matters yet, because that ambiguity alone is bleeding users.
Transparency at the point of risk. Next: are fees, exchange rates, and security cues clear exactly where the user is about to take a risk — or are they buried, vague, or worse, sprung at the end? I'm looking for the surprise fee, the FX rate you have to hunt for, the "link your bank" button with no reassurance anywhere near it. Trust-building starts with clarity at the scary moment, not fine print on a settings page.
Error prevention and recovery. Then the failure paths, which almost everyone under-designs. Can a user safely retry or resume a transaction that failed? When an ID upload fails mid-KYC, when a transfer times out, when the network drops during a payment — what happens? The happy path is easy and everyone designs it. The audit lives in the edge cases: the blurry document, the FX delay, the declined card. How a product behaves in those moments tells me more about its real quality than any polished dashboard.
The sensitive-data ask. How does the product request the things that scare people — Social Security numbers, account numbers, a selfie? Cold and contextless, or with a plain reason and a sense of safety? This single moment separates products that convert from products that get abandoned at verification, and I always check exactly how it's handled.
Compliance clarity. Are the consent screens, legal disclosures, and KYC steps actually readable and understandable — or are they walls of text a user clicks past blindly? Regulation doesn't have to feel like an interrogation. I check whether the user can understand what they're agreeing to and why, because confusion here reads as "this company is hiding something."
Performance as perception. And I always check speed on the flows that matter, because in fintech performance is trust. If a balance takes four seconds to load, it isn't technically broken — but it feels broken, and "feels broken" in a money app means "feels unsafe." A dashboard people use constantly needs to load in a second or two; anything over ten seconds on a core screen is a genuine problem, not a nitpick. Slowness at a moment of financial anxiety is a trust withdrawal, and I flag it like one.
None of this comes from a generic checklist. It comes from knowing, specifically, where financial products bleed — and going there first.
An audit that doesn't change anything is just an expensive PDF
Here's the part that separates an audit that's worth paying for from one that quietly dies in a shared drive: what happens after the findings.
The most common way audits fail has nothing to do with the analysis. It's that someone produces a beautiful eighty-slide teardown, presents it, everyone nods and says "great, really useful" — and then absolutely nothing changes. The findings weren't tied to anything anyone was accountable for, so they became another document collecting dust. A brilliant audit that drives no decisions is worth less than a rough one that changes a single flow.
So I build every audit to force a decision. That means three things. Every issue gets tied to a real metric the business already cares about — this friction is costing you KYC completions, this ambiguity is generating these support tickets, this dead-end is killing first-transaction conversion. Not "this feels off," but "this is costing you that." Then everything gets ranked by impact against effort, so the team isn't staring at a flat list of two hundred equal-looking problems but at a short, ordered set of "fix these first, they're cheap and they hurt the most." And it's delivered as a roadmap of decisions — what to fix, what to ignore, what moves the needle — not as a redline dump that offloads all the actual thinking onto the client. The report isn't the byproduct of the audit. The report is the product.
And part of doing this honestly is being clear about what an audit can't do — because overselling it is its own kind of failure. A UX audit will not tell you whether your product should exist. It won't fix product–market fit. It won't make people want something they don't want. It improves how your product works, not whether it should. I've watched teams commission an audit hoping it would validate a product users simply didn't want, and no amount of polish saves that. An audit finds friction, maps it to business impact, and shows you where trust is breaking. That's enormously valuable, and it's a specific, bounded thing. Pretending it's magic just sets everyone up to ignore the real findings.
That's the whole discipline, and it's the part that doesn't change no matter what tools or trends come through: know where trust is won and lost, look there first, tie every problem to money, and hand back decisions instead of redlines. The tooling evolves — new analytics, new session-replay, now AI that can flag patterns for you. The judgment underneath doesn't. Knowing which three flows carry the relationship, and which two hundred findings to throw away, is exactly the thing twenty years buys and a checklist never will.
If your product is bleeding users and you're not sure where, that's not a mystery to live with. It's an audit — a real one, aimed at the right three flows, tied to the numbers, and built to actually change something.
Strahil Hadzhiev
AUTHOR
