Role
Lead Product Designer
Sole designer
Sole designer
CASE STUDY · DIGITAL IDENTITY
Getting locked-out users back in, without the service desk
When people lost access to their digital identity, every recovery ended with a call to the service desk. I redesigned four fragmented, web-only flows into one self-serve native journey that routes five recovery scenarios safely, without loosening the security rules underneath.
Context: Digidentity is an eIDAS Qualified Trust Service Provider on the EU Trusted List, whose platform has created 25M+ verified identities across 180+ nationalities.
The Discovery
The Problem
Users who lost their device or got locked out faced a recovery experience that was web-only, fragmented, and full of dead ends, pushing most of them to the service desk. For a product handling legally binding credentials like eHerkenning and qualified signatures, a broken recovery flow doesn't just frustrate users; it erodes trust in the entire platform.
The result: recovery was neither self-serve nor scalable. The service desk had become the de facto recovery mechanism.
The opportunity: How might we…
- let users recover entirely within the mobile app, without bouncing to a web platform mid-flow?
- merge "recovery" and "transfer" when users don't understand or care about the distinction?
- balance non-negotiable security requirements with a self-serve experience that keeps users out of the service desk queue?
- design one flow that adapts to 5 different scenarios without overwhelming the user?
Who I Designed For
Individuals and business users across EU markets who hold legally binding credentials — eHerkenning, qualified electronic signatures, the EU Digital Identity Wallet — that they rely on for business operations, legal signatures, and government interactions. For these users a locked account isn't an inconvenience; it can block them from signing contracts, filing taxes, or accessing regulated services.
Constraints I Designed Within
01Users with multiple smart cards at the highest assurance level must re-upload evidence and re-create authenticators, a non-negotiable security requirement.
02Certain failure states must route to the service desk by design. That's a security control, not a bug to fix.
03PIN attempt counts are deliberately never disclosed to users.
04All copy has to work across 8 languages: short, modular, and translation-safe.
My Role, and Who Decided What
I was the only designer on this project, but recovery in a regulated product is a team decision. Here's where my ownership ended and my partners' began.
I led
- The audit of four existing flows and five recovery scenarios
- The phasing proposal: fix the web flow first, then go native
- End-to-end flow, routing logic and every screen, iOS and Android
- Failure and safety-net states, and all copy for 8 languages
I worked out with partners
- Routing rules for each credential level, with Security & Compliance
- Scope and release order, with the PM
- Feasibility and rollout, with engineering
- Scenario and edge-case coverage, with QA
Decided by others
- When biometrics vs. a document upload is required (Security)
- Which failure states must escalate to the service desk
- That PIN attempt counts are never shown to users
After handoff
- Design QA on builds before release
- Resolving edge cases with engineering during development
- Iterating on states once the flow was live
Strategy & Logic
What the Audit Revealed
The existing experience spanned four separate flows: web account creation, web password recovery, web recovery with no device access, and a parallel mobile journey. The longest path required 20+ screens and bounced users between web and mobile via QR codes. The forgot-password flow had dead ends where users with a wrong or forgotten email simply had nowhere to go.
Web recovery journey: before vs. after
Cross-device recovery: from app to web
Complaints & dead ends
Options I Weighed
APatch the web flow and stop there. Fast to build, but most users are mobile-first and would still bounce between app and web.
BA big-bang native rebuild. The right end state, but users would wait months with no improvement at all.
CFix the web now, build native properly next. Chosen: an immediate fix within engineering capacity, without compromising the long-term solution.
A Phased Approach
Rather than make users wait months for a big-bang release, I sequenced the work to match development capacity, delivering an immediate improvement while the right long-term solution was built properly.
Phase 01 · Early 2025
Stabilise the web flow
Fixed broken links, removed dead ends, and streamlined sequencing on the existing web recovery. A lighter lift for engineering that gave users an immediate improvement.
Phase 02 · Late 2025 →
Reimagine for native mobile
Moved recovery to a fully native mobile flow — no more web handoffs — and consolidated "Recovery" and "Transfer" into a single entry point as part of the move.
The Pivot
The hardest part wasn't the visible flow: it was the rules underneath it. The distinction between when biometric verification was required versus when an ID-document upload was sufficient only became clear after several rounds of iteration with the security team.
That single clarification reshaped the whole solution: it's what split recovery into three distinct happy paths.
Once I understood the assurance rules properly, the design stopped trying to force one universal flow and instead routed each user down the correct path for their credential level. The lesson I carry forward: in regulated products, pin down the compliance logic before designing the screens, not during.
Phase 2 recovery routing: three happy paths
Selfie happy path (profile picture available, except Lvl 4)
The Execution
The Final Flow
A fully native recovery experience covering three happy paths plus the corner cases that matter most: invitation + recovery, sign/login + recovery (handled inline via push notification, returning users to their original task), and suspected fraud, where the user sees a clear "unusual activity" explanation and is guided through identity verification and a new PIN, with no dead ends.
When profile picture available (except smartcard Lvl 4): selfie route
Profile picture available (Smart 4) or profile picture unavailable: document upload required
Recovery flow for suspected-fraud users
Safety Nets
Users who attempt recovery too many times are redirected to the service desk with a clear message: an intentional escalation, not a dead end. Failure states were redesigned to explain what happened and offer a next step, rather than showing an error icon and stopping.
Design options for the pending state
Recovery status: product active vs. unable to activate
How I Validated It
Getting clients into testing sessions for a regulated identity product was hard, so I ran user acceptance testing internally with the service desk team. They were the right proxy: before the redesign they had handled every recovery by hand, so they knew exactly where people got stuck and which scenarios broke.
It's not the same as watching real users recover their accounts, and I treat it that way. The service desk's post-launch reporting is what confirmed the flow worked in the wild.
Design System & Accessibility
Built on Digidentity's native component library for consistency across the app: the recovery screens share the same visual language as the rest of the product. Every screen has a clear hierarchy so users always know what's happening, why, and what to do next, and all copy was written short and modular to localise cleanly across 8 languages.
The Conclusion
Results
Before this project, recovery had no self-serve path at all: every case went through the service desk. In the first month after the native flow launched, 86% of users who went through recovery completed it themselves, without calling support.
WhatShare of users going through recovery who finish without contacting the service desk
Baseline0%: before the redesign there was no self-serve route, so every recovery became a support case
PeriodSeptember to October 2026, the first month after launch
SourceReported by the service desk team, who handled every recovery before the redesign
100% was never the target. Some failure states route to the service desk on purpose as a security control, so part of the remaining group is the system working as intended. One month is an early signal, not a settled result, so I'm continuing to track it.
Reflections
I'd involve engineering earlier in the mobile phase: some technical constraints surfaced late. And I'd lock the smart-card assurance and authorisation requirements with the security team up front; getting that clarity earlier would have saved significant rework and reached the right solution faster.
Next, I'd want in-app measurement on each of the three routes, to see exactly where the remaining users leave for the service desk, and whether those exits are intended security escalations or friction we can still design out.
Collaborators
A cross-functional effort across the team. I credit each partner by role: