OneID
Verification.

Identity verification is a moment of high stakes and low trust. You're being asked to hand over sensitive personal data to a service you may have just discovered. The bar for confidence is high, and the tolerance for friction is almost zero.

At OneID, that tension sat at the centre of everything. We had three groups of people with overlapping but often conflicting needs, and designing for one without the others created problems fast.

The research made one thing clear: we couldn't fix everything at once without breaking what was already working. Completion rates were suffering at specific, identifiable points — not everywhere. So we split the work into three phases, each one building on the last.

This wasn't just a sensible project plan. It was a way of protecting the team: giving engineering fast wins without betting on architectural decisions we hadn't validated yet.

These changes focused on reducing cognitive load at the most sensitive points of the journey — particularly where users were asked to connect their bank.

The design system built during this project became its own case study — explore how it was built →

The first phase delivered real gains (~+27% completion). But it exposed something we'd been working around: bank verification alone couldn't serve everyone.

Users without digital bank accounts. Joint account holders. People outside the UK. E-commerce scenarios where speed was everything. These were whole groups of customers we couldn't reach.

We began adding alternative verification methods — document scanning first, then a growing set of identity providers for different regulatory contexts.

This was the moment that changed how I thought about the product.

Until now, OneID sold named products — ID Check, ID Assure, Age Check, Age Assure — each a fixed solution for a specific use case. Customers had needs that didn't map cleanly to any single product. New use cases kept arriving. Every addition created another thing to maintain, position, and explain.

Under the hood, this meant restructuring OneID around an orchestration layer. Verification methods became modular components that could be combined per context. From a customer's perspective: instead of choosing between products, they were shaping one.

Orchestration introduced real backend complexity and significant upfront engineering. But it was the only model that could scale — no fixed product catalogue would ever keep pace with how compliance requirements actually evolve.

By this point, OneID was processing around 800,000 verifications a week — 300× the volume when I joined. At that scale, even small inefficiencies compound fast.

The cost model had a structural problem: every verification had a per-check cost, including for returning users. Someone signing documents in DocuSign three times a month was being verified from scratch each time. Meanwhile, competitors with app-based models were building loyalty out of reuse.

We introduced OneID Accounts: a way for users to save their verified results and unlock them again with a passkey, with end-to-end encryption ensuring only they could access their data. The result was a 2/3 reduction in cost per check for returning users.

Reuse was the first step in building a relationship to maintain. But it surfaced a gap: users had no visibility into their own verified identity. They couldn't see which organisations had checked them, manage their data, or delete their account without contacting OneID directly.

I'm currently designing MyOneID — a user-facing portal that gives people genuine control over their identity data. Not just GDPR compliance as a backend function, but transparency as a product feature.

If orchestration made OneID more powerful for businesses, MyOneID is what makes it trustworthy for the people at the centre of it. Identity verification, done right, shouldn't feel like something that happens to you. It should feel like something you're in control of.