Designing an identity verification experience that's easy to use

At a glance

• A verification journey designed around real people, from personas to MVP
• Shipped white-labelled and device agnostic
• Went on to become a government-approved digital identity verification platform

The problem

Verification is high friction by nature. It makes people stop what they were doing, find an ID document, complete a liveness check and sometimes upload supporting documents. Every one of those steps is a place to drop off.

And there were limits on what I could change:

• The rules. Regulation decided which checks had to happen.
• The technology. The liveness check and document capture came from the verification vendor.
• The context. Customers might reach the journey at sign-up or weeks later from an email, on whatever device they had. Clients could embed it in their own pages, link to it on its own URL or use the API.
• The brand. It had to look and feel like each client. Verification is often a customer’s first real interaction with a business, and they don’t know who built it. A smooth one is a competitive advantage. A poor one reflects badly on the client.

The solution

1. Starting with personas

I built personas from research on past implementations, which gave the team specific people to design for. They covered everyone who used the product, including the back office staff who set up each client’s theme. Some focused on accessibility needs.

2. Deciding what to build first

I split the journey into steps, wrote user stories for each and linked them back to the personas. That made it easier to agree on what to ship first, which is usually the hardest conversation on a project.

Three features came out of the process:

• Moving a session to another device
• Uploading a picture of an ID manually
• Guided capture with real-time feedback

Each one removed a dead end that real people had hit in past implementations.

3. Smoothing out the sticking points

• The start. Most people arrived unprepared, so the journey now tells them upfront what they’ll need and how long it takes.
• Equipment. If someone has no webcam or their device fails a device check, the journey now offers another way to proceed.
• Capture. The hardest part. I worked out that the size of the frame lines and the video player sets how far away someone holds their phone. If those are off, people end up holding their device too close or too far away.

4. Designing the unhappy path

I wireframed every point where something could go wrong: a one-time password error, a device check that fails, a verification that comes back negative. Each one gives the customer a clear next step, so a problem never has to end the journey.

5. Fixing what I could control

The liveness check included a voice-to-text comparison, which proves there’s a real person in front of the camera. People had to read aloud a random set of numbers shown on screen.

In testing, most people shown “33-44-11” read out “three three four four one one”, but the check expected “thirty-three forty-four eleven”. So genuine people were failing.

I couldn’t change the spoken test, as that was part of the vendor’s technology. So I changed how the numbers were formatted on screen, and people started reading them the way the check expected. Successful verifications went up noticeably.

Outcomes

• Vaiie Identify shipped white-labelled and device agnostic. Each client could make it their own, and customers could get through it on whatever device they had.
• Reformatting the numbers in the liveness check increased successful verifications, without any change to the vendor’s technology.
• Identify went on to become a government-approved digital identity verification platform.