Read time: 4 minutes

Reusable ID, Reimagined for Speed

Reducing Friction and Cost with Reusable Digital Identity

Teams

Product team size 6

Sole designer

Role

Senior UX Designer

Company

OneID

Impact

🚀 Completion time for returning users cut to 5 seconds - vs. 12s for no-document checks and 1m25s for a document scan + face match.

The Problem

Identity verification can introduce significant friction: it interrupts tasks, requires digital fluency, and often leaves users feeling unnecessarily scrutinised. OneID helps people verify who they are quickly and securely, typically without scanning documents or taking selfies.
(Read the full Document-Free ID Check case study for more on that solution.)

For end-users, the experience is fast. For customers, it means higher conversion and lower fraud. But over time, three key challenges emerged.

Challenges:

  • Returning users had to start from scratch every time, which caused frustration.

  • Competitors like Yoti offered smoother re-verification flows.

  • Internally, repeating verifications means paying again for the same data, an approach that doesn’t scale.

The Opportunity

We saw a chance to improve both the user experience and business performance by introducing a reusable, cloud-based solution. It could:

  • Reduce friction for users during repeat verifications.

  • Lower costs by avoiding repeated data-source lookups.

  • Increase product stickiness and encourage return usage.

  • Support revenue growth through better unit economics.

Strategic Approach

We set out to design a cloud-based identity wallet — a secure layer that would let users store and reuse their verified data across sessions and services. The solution needed to be:

  • Secure by default, but effortless for returning users.

  • Cross-platform, working seamlessly on both mobile and desktop. No app download.

  • Extensible, allowing users to update or add new credentials.

  • Cost-efficient, reducing OneID’s per-verification spend and supporting the business revenue growth plans.

UX Principles That Guided Us

  • Cognitive Load Theory: Inspired by services like Shop Pay, we aimed to make the data storage feel as natural as possible, without disrupting the overall identity check flow.

  • Jakob’s Law: We mirrored familiar passkey UX patterns from platforms like Apple and Google to reduce learning curves and build trust.

This foundation helped us make smart trade-offs across UX, engineering, and policy - balancing security, usability, and scalability from day one.

User feedback

“I work dealing with contracts. I verify my identity to add my e-signature every day.

Can you not remember me?”

Mats Lederhausen

“Think big, start small, then scale or fail fast.”

PASSKEY

The death of passwords?

Fido Alliance

“A passkey is a FIDO authentication credential based on FIDO standards, that allows a user to sign in to apps and websites with the same process that they use to unlock their device (biometrics, PIN, or pattern). Passkeys are FIDO cryptographic credentials that are tied to a user’s account on a website or application. With passkeys, users no longer need to enter usernames and passwords or additional factors. Instead, a user approves a sign-in with the same process they use to unlock their device (for example, biometrics, PIN, pattern).”

Authentication

OneID can leverage bank data as a no-document, fast way to prove your identity. However, re-authenticating to OneID via bank login every time felt unnecessarily heavy-handed and defeated the revenue optimisation goal. We explored alternatives and zeroed in on passkeys, an emerging FIDO-based standard already in use by Apple, Google, and PayPal.

We tested this in a lightweight prototype with 100 users:

  • 50 saw a passkey prompt, 50 didn’t.

  • 48 of 50 opted to create one—citing biometric login, speed, and familiarity with Face ID as key motivators.

This validated passkeys as a viable solution. Still, adoption wasn’t universal, so we designed a tiered fallback system based on device/browser capabilities:

  1. Passkey-enabled device → Direct login.

  2. Desktop with no passkey support → QR redirection to the user’s mobile device.

  3. Mobile with no passkey support → OTP. This gives OneID just enough security to suggest the user what bank was linked to their OneID. The users will then need to login to their bank app and share a subject identifier, which will log them in to their OneID.

We proposed additional methods like magic links, but in tight dev resourcing, we launched a slim MVP with capabilities we had on the shelf to gather early feedback.

Account recover

We anticipated that users could lose access to their passkeys (e.g., changing operating system). So we designed for 2 recovery cases:

1. OneID account exists, passkey created but not found

Users will authenticate in the same of non-passkey accounts - enter an OTP and log in to the same bank connected to OneID.

2. Authenticated to OneID account, no encryption key found

We can only see what type of detail have been verified by users, but not the detail itself. The passkey is used to decrypt the user’s data, ensuring only they can have access to it. Sometimes that key can fail, and even if the user logged in, they can’t access their details to manage or share. In that case, we don’t need OTPs, we can remember users what bank was linked at registration.

MVP Trade-Offs

The initial build allowed:

  • Secure data storage tied to a passkey.

  • Re-authentication without re-verifying identity details.

  • Basic fallback options (OTP + bank).

However, data updates were handled as full overrides—if you added a new address or switched bank accounts, previous data was wiped. This was technically simpler but not ideal from a user perspective.

As a user experience designer, I challenged this. Identity data needs to meet certain GPG45 confidence standards, but it can be modular - a name from a document, an address from a bank, a date of birth from mobile records. Overwriting verified information undermines user control and trust.

But with only one potential customer for the Wallet plugin, and one verification use case in the pilot, we compromised on speed to market, with a plan to expand to partial updates and source tagging in the next phase.

Iteration Strategy

We rolled out the Wallet MVP with one ‘friendly’ customer and tightly scoped data requirements. This allowed us to:

  • Observe real-world passkey usage across devices.

  • Measure reductions in drop-off and time to verify for returning users.

  • Identify edge cases and error states we hadn’t caught in prototyping.

🔁 The second iteration will prioritise:

  • Granular data updates (without full overwrites).

  • UX messaging to give more information on MyOneID where users can track and manage their data shared.

  • Cross-device continuity, especially on shared or work-owned devices since passkeys are tied to the operating system (e.g., Apple iCloud account or Google Account).

Results

FIRST ITERATION

🔁 Returning users now verify their identity…

(and/or address, date of birth, bank account details, anti-fraud, AML alerts, etc…)

21x faster

than re-verifying it through document scanning

4x faster

than re-verifying it through their bank

Press ‘ Play’ to watch it for yourself…

Other insights:

  • ~80% of eligible users opted into passkeys, validating it as a preferred method for seamless re-authentication.

  • However, 31% of those users experienced passkey failures. Since the authentication process happens within the device OS, the root causes weren’t always visible to us — even on devices that were technically compatible.

  • iOS had the lowest error rate, which helped us prioritise platform-specific improvements.

  • We also uncovered a critical issue: SMS codes were not being delivered to users in certain countries, due to limitations in our provider’s coverage. We addressed this within days of identifying the gap.

  • Conversion of returning users increased 15%. Honestly, we anticipated more considering how sleek the flow became.

Next steps

  • Further optimise conversion through insight-driven iteration
    We’re actively investigating how to increase conversion by combining qualitative feedback (via user testing on Lyssna) with behavioural analysis (via PostHog and DataDog). This helps us pinpoint failure points in the data-sharing flow and refine the experience accordingly.

  • Explore alternative authentication methods
    While passkeys have proven effective, it’s not fully supported. We’re assessing additional secure, fast, and accessible authentication options — particularly for edge cases where passkeys can’t be created.

  • Introduce the OneID Wallet portal to users
    The Wallet portal is nearing readiness. Soon, we’ll incorporate it more visibly in the user flow to build transparency and trust — giving users a clear view of their verified data and the consents they’ve shared.