A self-serve identity-verification platform · Case study

Problem

Organisations (corporates and government agencies) periodically need to confirm that a person is who they say they are and is still active: pension beneficiaries, staff audits, driver ID checks. The platform turns that into a campaign: upload a participant list, share a link, and each person completes a face capture matched against their government identity record. It spans three surfaces with very different users.

Clients need to launch a campaign in minutes, watch it fill up, and export records that hold up to scrutiny.
End users are often non-technical, on any phone, and will abandon anything that feels like a form or asks them to make an account.
The platform needs an audit trail: who verified, when, with which photo, and why a verification failed.

Evidence / research

The starting point was a written concept note describing campaign-based photo verification against a government identity record. I worked from it to map the three audiences, client organisations, platform administrators and participants, and what each one needs from the same verification event: a client needs a defensible record, an administrator needs to see why a check failed, and a participant needs to get through it on the first try.

My role

I designed the client dashboard and internal admin console from the written specification, including flow and error states and per-participant audit records. Another UI/UX designer worked on the email templates and mobile views.

Constraints

Participants could arrive on different phones with little technical experience. The flow depended on camera access and an upstream identity service, while organisations needed records suitable for audit. Identity numbers needed masking in the interface.

Options considered

Two tradeoffs mattered most. Asking participants to create an account is the standard way to gate access, but for a pensioner on an unfamiliar phone it is one more place to give up; gating eligibility by the campaign list removes that step entirely. And a single generic “verification failed” message is simpler to build, but it gives a participant nothing to act on and gives an administrator nothing to defend. Specific recovery states cost more design and engineering, and they turn a dead end into a next step.

Decision

No account for end users. The design hypothesis was that account creation would add friction; eligibility is gated by the campaign list instead.

Guide the capture, check on the device, let people retake. Pose steps, quality checks and a preview-before-submit aim to reduce failed captures and the support calls that follow them.

Show both photos and the exact failure reason on the record. Verification gets contested; the record has to make the outcome defensible on its own.

Mask the identity number in the UI (LAG***45). Data minimisation by default.

“Upstream API down” is not “verification failed.” In a flow tied to someone’s pension, an infrastructure error must never read as the person failing a check.

Design

The connected experiences

Client dashboard: a home view with campaign totals, active-campaign count, participant volume and success rate at a glance, plus a verification-outcomes split and a trend over time, so a spike in failures is visible before it turns into a support ticket. From there: a searchable, filterable list of every campaign, create a campaign (name, objective, dates, participant CSV with validation), monitor it, drill into per-participant records (submitted photo vs. record photo, status, failure reason), export reports, and manage sub-admins with scoped roles.
Admin console: a client approval queue (validate registration documents and director IDs), account controls (pause / deactivate), and a platform-wide audit trail and metrics.
End-user capture: a no-login mobile-web flow. Enter ID → eligibility checks → guided face capture with on-device quality checks and retake → a clear result. Every failure and edge case is a designed state (campaign paused, already verified, face mismatch, ID not found, camera denied, poor lighting, upstream API down), not a dead end.

Client dashboard home screen with total and active campaign counts, total participants, success rate, a verification-outcomes donut chart, a verifications-over-time trend line, and a recent-campaigns table — Client dashboard: campaign health at a glance, before drilling into any one campaign

Campaigns list with campaign ID, name, start and end dates and status, searchable and filterable by status — Campaigns: every campaign a client has run, searchable and filterable by status

Create-campaign modal — From there: create a campaign from a participant CSV

End-user eligibility step — End-user flow: eligibility gate before any capture

Screen reading 'This campaign is currently paused' — A paused campaign reads as a status, not a broken app

Screen reading 'You've already completed verification' — Already verified: no re-attempt required

Guided face capture — Guided capture: pose steps, on-device alignment feedback

Opening a campaign from the list surfaces its own numbers, participants, verified, pending, failed, success rate, next to the verification URL, its active period and a change log of who edited it. Every row in the participant table underneath links out to that person’s own record.

Single-campaign detail screen with participant, verified, pending, failed and success-rate stats, campaign metadata, and a per-participant table with a Details link on each row — Inside a campaign: its own stats, its own participant table, one Details link per row

Per-participant verification record showing a successful match — Successful: submitted vs. record photo, masked ID

Per-participant verification record showing a failed match with a face-mismatch reason — Failed: same record, with the reason stated

Campaign verification report — Campaign report: exportable, per-participant, with reasons

Collaboration / implementation

Over two months, I worked with the product / business analyst, another UI/UX designer and engineering to translate the written concept into three connected experiences. I focused on the client dashboard and internal admin console, while the other designer worked on email templates and mobile views. Together, our design scope covered the main verification path and its error states.

Measurement

Pilot adoption, capture-flow completion rate, and time-to-verify against the in-person process it replaces are still early. I hold them as targets rather than confirmed results, with firm figures to follow once there is a stable stretch to report.

Result

One product now runs across three surfaces, a client dashboard, an admin console and a no-login end-user capture flow, on a single audit trail. Getting verified takes zero accounts, and 8+ failure and edge states, a paused campaign, an already-verified participant, a face mismatch, a denied camera, an upstream outage, are designed states rather than dead ends.

What I learned

This project sharpened how I think about failure messages. A face mismatch, a denied camera permission and an unavailable identity service mean different things and require different next steps. The interface needs to explain that distinction clearly, especially when a verification affects access to an important service.

I also learned to consider the participant’s experience alongside the record an administrator will review later. Guided capture and a clear audit trail support different parts of the same process. My next priority would be testing the recovery instructions on a range of phones, with people who are unfamiliar with online verification.