Building for the paths that fail

Identity verification was failing the people it was meant to let in. The fix wasn’t a screen — it was the system underneath, and following it there was the real design work.

Role
Product Designer
& Manager
Timeline
2026
Team
4 Engineers
2 Compliance
2 Designers
Skills
System & State Design
Interaction Design
UX Copy
QA

Omits runs every new user through identity verification — KYC, handled by our partner Persona — before they can transact. This is about the people who couldn’t get through, and what it took to give them a way.

We’d only built the happy path

We were getting close to beta, so we opened Omits up to around a hundred people. It didn’t take long for the same thing to keep coming back: some of them couldn’t get verified.

So I went in to run the flow myself. KYC isn’t something you can judge from a Figma file — the flow is defined by Persona, the partner running our checks, and the only way to really understand it is to go through it. Two things stood out. If I left the app partway through and came back, it didn’t pick up where I’d left off — it started me over. And when I failed the check, even after Persona’s built-in retries, nothing stopped me from starting the whole thing again, and again, as many times as I liked.

That last part hurt in three directions at once. Every check we ran cost money, so a person failing in a loop meant paying to verify them over and over — and nothing stopped someone from doing that on purpose. We also had no answer for the people who genuinely couldn’t get verified; we’d built the path that works when everything goes right and nothing past it, so a failed user just stopped. And as more testers came through, a pattern showed up: when someone’s document couldn’t be verified and it was the only one they had, the app left them there, repeating the one thing that would never work.

Underneath all three was the same truth — we didn’t really have a KYC flow. We had the happy path, and nothing for the people it failed. That’s a UX problem, an expensive one, and it’s not the kind you fix by redrawing a screen.

Into the system

The fix was never going to come from the surface, so I went under it — into how a Persona check actually works. Each one is a small lifecycle with a handful of states and a single rule that governs everything: once a check fails, it’s final. It can’t be approved and it can’t be reopened — not by support, not by a reviewer, not by the user trying the same document again.

The shape of a single check — created, submitted, then final.

The distilled inquiry lifecycle — created, submitted, completed or failed, and the post-inquiry status

To design around that, I had to see the whole thing. So I mapped it — every state and branch, the automated flow and the manual one we didn’t have yet — and worked from that map with engineering. This is the part of design that doesn’t look like design: no screens, just the logic that decides what every screen will ever be allowed to say.

The whole system I mapped around it — every state, both flows. Open it to read the detail.

The full KYC system map — the automated flow and the manual flow, every state and branch, annotated

Most of the loop closed right here, out of sight. Persona could already keep one thread per person and resume an unfinished check — our build had simply never asked it to. I went through the docs, wrote down the integration we should have had, and the team rebuilt to it: one identity per user, a check that resumes instead of restarting, and a guard that won’t open a new one on top of a check that’s still running or already failed. The endless retry, and the money leaking through it, stopped there.

That wasn’t the fast option, and I had to argue for it. Engineering wanted to patch the surface and move on; I pushed to build the unglamorous half properly — the state handling Persona already gave us for free. The patch would have held right until the rewrite we’d have been forced into later, under more pressure. Doing it once was the shorter road. It took a few rounds to land that; they gave it the time.

Osaro’s ability to communicate with both technical and non-technical stakeholders made him a valuable bridge between product vision and implementation.
Michael OmitiranFounder & CEO, Omits

Building the way through

Closing the loop meant fewer people got stuck in it, but some still couldn’t pass — their document wouldn’t verify and it was the only one they had. A failed check can’t be undone, so the answer was never to retry it. It was to build the thing the product never had: a way for a real person to reach a real reviewer.

Now a user who fails can submit their details through a secure form, and it goes to someone who can actually help.

The four steps a failed user now moves through.

The four mobile steps — the failed check, the prompt, the secure form, and submission received

Where that data went was its own decision. The easy place was the support inbox, since the conversation was already there — but government IDs and selfies don’t belong somewhere any agent can open them and where you don’t control retention. So the submission splits: the user keeps a line to support in Intercom, and the documents go into our own admin, under Compliance, where only the people meant to see them can.

Inside our admin — where a reviewer picks it up.

Approving them was the part I’m most proud of. The failed check stays failed — the record should never say someone passed when they didn’t. But the screening that legally has to happen still runs: an approval starts a separate Persona transaction for just that, the watchlist and PEP checks, with nothing more asked of the user. The record stays honest, and the person still gets through.

Not every failure was loud, either. Persona reads the name off the document, and on most passports the given names share one line — so a Nigerian user with a first and a middle name comes back as one first name. Osaro Ochuko, saved wrong, permanently, and nobody would catch it until a support ticket months later. So I added a step: show people the name we pulled before we save it, and let them correct it, with the change logged for the reviewer.

The last piece was the waiting. Someone who just failed and is now waiting on a human assumes the worst if nothing reaches them — so the status comes to them: an email as the review moves, and a badge in the app that shows where they stand the moment they open it. Nobody waits in the dark.

Before and after — from no signal to a status you can see.

Before and after: the verify-identity row with no status, then with a clear status badge

What changed

We were still pre-launch, so these are early signals from a small group, not settled numbers — but the shape was clear.

~25%

More recoveries, from a starting point of none

~60%

Less verification spend, once a failed user couldn’t trigger another paid check

~20%

Fewer duplicate inquiries, one person no longer scattered across entries

And the loop — the thing that started all of this — was gone.

Osaro played a pivotal role in bringing structure and discipline to the Product and Engineering team. He demonstrated a rare combination of technical understanding, design sensibility, and operational rigour.
Ayobodun AjepeHead of Operations, Omits

What I keep from it is simple: I’d rather follow a problem to wherever it actually lives — a tester’s frustration, a partner’s docs, a flow no one had drawn — than stop at the edge of the screen. At Omits, that’s where the work that mattered was.