SUSHARA / 2026CASE STUDY
DIGIDENTITY — NFC ID FLOW
CASE STUDY · DIGITAL IDENTITY

Bringing NFC ID verification in-house

Digidentity verified people's identities through ReadID — a third-party NFC SDK we didn't control. I designed the in-house replacement end to end, from illustration and animation to the full UI and UX, so the company could finally own the most critical moment in its product: proving you are who you say you are.

Context — Digidentity is an eIDAS Qualified Trust Service Provider on the EU Trusted List, whose platform has created 25M+ verified identities across 180+ nationalities.

Role
Sole Designer
illustration → UX
Timeline
Apr 2024 → present
Phase 1 shipped
Platform
iOS + Android
passport · ID · licence
Impact
Third-party SDK → owned flow
FIG. 01 / FINAL
Add hero image — the final NFC scanning flow across passport, ID and driving licence

The Discovery

The Problem

Identity verification — the single most important action in our product — was outsourced to ReadID, a third-party NFC SDK. We couldn't shape the experience, the branding, or the cost. Bringing it in-house meant ownership, but NFC scanning is genuinely hard for ordinary people: most users don't know what an MRZ is, where the NFC chip sits inside their document, or how to hold the phone steady long enough to read it.

And every failed first attempt turns into a support ticket — so the experience design wasn't a nice-to-have, it was the difference between a verification that completes and one that lands on the service desk.

The opportunity — How might we…
  • own the most critical moment in our product instead of renting it from a third party?
  • guide a non-technical user through an NFC scan they've never been taught to do?
  • strip out the steps and decisions that make first-attempt scans fail?

Who I Designed For

EU citizens verifying a government-issued document — passport, national ID card, or driving licence — on their own phones, across iOS and Android. Largely non-technical, operating across eight languages, and often doing this for the first time under a little pressure.

Constraints I Designed Within

01NFC chip behaviour differs by document and device — and unlocking the chip at all requires the document number, date of birth and expiry date, data the user otherwise has to type by hand.
02Limited engineering capacity, and as a regulated identity product, security and compliance shaped every decision.
03Phase 1 carried a clear mandate from senior stakeholders: mirror ReadID as closely as possible to de-risk the migration.

Strategy & Logic

The Core Decision: Two Ways In

An NFC read can't happen until the app has the document's key data. There are only two ways to get it: make the user type it — more steps, more errors — or scan the machine-readable zone to capture it automatically. I mapped both and argued for the second: MRZ pre-validation, to collapse the steps and take decisions off the user's plate.

FIG. 02 — Add image
The two routes side by side — manual entry vs. MRZ pre-validation — showing where steps and decisions drop out.

One Pattern, Three Documents

Passport, ID card and driving licence each got their own positioning guidance, scan sequence, and success / error states — unified under a single, consistent pattern so the flow felt like one product, not three.

Instruction as a Design Discipline

Because users didn't understand the MRZ or chip placement, instruction became a craft in its own right. I designed and illustrated animated guidance showing exactly how to position the phone against each document type — the hand-holding ReadID never offered.

The Pivot

I advocated for MRZ pre-validation from the start. But technical difficulty and limited capacity led senior stakeholders to overrule it for Phase 1 — the directive was to replicate the ReadID steps as faithfully as possible and de-risk the launch. That meant a longer flow and a heavy dependence on instruction.

I held a deprioritised idea in reserve — MRZ pre-validation — until the constraints that killed it finally lifted.

Replicating ReadID surfaced exactly the friction I'd predicted: without pre-validation, users were left to understand the MRZ and scanning on their own, so the whole flow leaned on instructional animation to carry them through. The pipeline was constrained too — engineering pushed back hard on Lottie, so I built everything in Figma, screen-recorded to MP4, and compressed the files through HandBrake to keep them shippable. And it was all iPhone-first.

Then in Phase 2, stakeholders asked to cut screens and steps — which led straight back to the MRZ pre-validation flow I'd originally proposed. I'm now reverse-engineering toward it. Engineering also adopted Lottie at last, letting me replace the heavy MP4 workaround with lighter, per-device animations instead of one iPhone-centric set.

Phase 1 · 2024

Replicate & instruct

MRZ pre-validation deprioritised; the ReadID steps mirrored to de-risk the launch. Heavy instructional animation, built Figma → MP4 → HandBrake, and iPhone-first.

Phase 2 · 2026 →

Fewer steps, my way

The org circles back to MRZ pre-validation. Screens and user decisions cut, Lottie adopted at last, and animations rebuilt per device — a cleaner, more scalable foundation.

FIG. 03 — Add image
Annotated before / after — the replicated ReadID flow vs. the leaner MRZ pre-validation flow.

The Execution

The Final Flow

A complete, in-house NFC verification flow for passport, ID card and driving licence — instructional animation for phone positioning, the scan sequence, and clear success / error handling — live on both iOS and Android. I owned every layer, from illustration through to production UI.

Built on the Design System

I built the flow within the Digidentity design system, keeping the three document journeys and both platforms visually consistent and fully localised across eight languages.

Animation Craft

Phase 1 was a study in working within constraints — Figma → MP4 → HandBrake when Lottie wasn't on the table. Phase 2 moves to Lottie with device-specific guidance: a cleaner, more scalable foundation.

Accessibility

Instructional clarity for non-technical users sat at the centre, alongside colour contrast, tap-target sizing, and full localisation so the guidance reads naturally in every supported language.

FIG. 04 — Add image
High-res final screens across the three document flows — a short scan clip or prototype lands hardest here.

The Conclusion

Results

Phase 1 shipped: Digidentity now runs its own NFC verification instead of ReadID, owning the experience and removing the third-party dependency — across three document types, two platforms, and eight languages.

Note to self: add post-launch numbers here — first-attempt scan success, NFC-related ticket volume, and drop-off by step and platform — once the metrics wiki data is in.

Reflections

With more capacity up front, MRZ pre-validation would have shipped in Phase 1 and saved a redesign loop — and earlier Lottie adoption would have spared the MP4 / HandBrake workaround. The phased reality taught me something I value now: keep a good idea documented and ready, because the constraints that kill it today often lift tomorrow.

Collaborators

Product Owner · prioritisation Security & Compliance · requirements External Developers · build Supporting Designer · cover during leave
Next case →

One account, one PIN

Read next case →
↳ AMSTERDAM · 52.37° N RHEA SUSHARA · CASE STUDY