LEAN ID

Redesigning Identity Verification at a Systems Level

Identity verification flows fail when nobody holds the full picture. On LEAN ID, I was that person.

YEAR

2026

COMPANY

Verimi

STAtus

Partially shipped; company wound down before go-live.

Identity Orchestration

Identity Systems

eIDAS

Flow Architecture

Stakeholder Alignment

Cost-Aware UX

WHAT

Ground-up redesign of identity verification for partners in regulated industries — one unified flow, login removed as the gate, proprietary app dependency dropped

INDUSTRY

Digital identity · regulated (eIDAS, QES, GDPR)

Role

Senior Product Designer — mapped the full system (flows, dependencies, partner implications, regulatory constraints, cost structure); wrote the system documentation product decisions were made from; carried the login-removal case to product leadership; coordinated open questions across legal, engineering and partner management

Team

PM, PO, architect, designer, engineering, legal, partner management, FE

TIMeline

January - July 2025

Key decisions

Built and carried the case for removing login entirely, with account creation optional at the exit · repositioned identification methods as options under one selector, not separate flow states · replaced the proprietary app with the official government eID client plus email OTP — a bounded, documented security trade-off · defined the KPI framework where no measurement existed

Constraints

eIDAS and GDPR · partner contracts constraining the flow · provider cost structure · eID across iOS, Android and desktop

result

Proprietary app dropped for the government eID client + email-OTP 2FA — shipped, eliminating a five-figure monthly cost · flow redesign (minimum five steps removed from every journey, login removed as the gate) completed and approved for release; company wound down before go-live · system knowledge documented in one coherent place for the first time · measurement framework defined for attribution

Figures generalised for confidentiality

The problem

Verimi provides identity verification, authentication and qualified electronic signing (QES) infrastructure to partners in regulated industries. In 2026 it launched LEAN ID: reduce operational cost, simplify infrastructure, redesign verification from the ground up.

The existing system had accumulated structural complexity, and the data made its cost measurable.

Measured before LEAN

Behind the numbers, four structural problems compounded: users were split into multiple flow states inside what was nominally one flow — and one identification method had been incorrectly treated as a flow state rather than a method-selector option, adding architectural weight to a distinction that didn’t need to exist. Login gated every user, adding a minimum of five steps to every journey. Critical system knowledge lived only in people’s heads. Partner integration requirements, prior accessibility work, and data-retention rules were scattered rather than held in one place. And no single person held cross-functional visibility, so decisions in one domain had unexamined implications in another.

Behind the numbers, four structural problems compounded: users were split into multiple flow states inside what was nominally one flow — and one identification method had been incorrectly treated as a flow state rather than a method-selector option, adding architectural weight to a distinction that didn't need to exist. Login gated every user, adding a minimum of five steps to every journey. Critical system knowledge existed only in people's heads — partner integration requirements undocumented, a built-but-never-activated duplicate-account solution, accessibility work unknown to the team, retention periods never mapped against actual regulatory requirements. And no single person held cross-functional visibility, so decisions in one domain had unexamined implications in another.

The five domains the flow touched — and the cross-domain layer I held across them.

What I did

Mapped the full system before touching any flows.

All flow states, user types, identification methods, partner touchpoints, regulatory dependencies — the first complete picture of how the system actually worked versus how it was assumed to work. The gaps above came out of this mapping; each was documented, connected to its owning discipline, and turned into a decision or an open question with a name on it.

Identification methods as options under a single decision point, not separate flow states.

Drove the decision the data demanded: removing login.

Login gated everyone, served fewer than one in twenty, and was the single largest drop-off point. I built the case for removing it entirely and carried it to product leadership; engineering confirmed the unified flow was implementable without breaking partner APIs. In the shipped flow, verification requires no login; account creation is an optional final step; returning users with accounts keep streamlined re-verification. Minimum five steps removed from every journey.

Resolved the stored-identity architecture question.

A method cut from scope early was reinstated when a major integration partner objected. I repositioned it correctly — a method inside the selector, not a separate flow state — satisfying partner requirements without reintroducing the complexity we had just removed.

Removed the proprietary-app dependency.

eID now runs through the official government client (AusweisApp Bund) on every platform — app-not-installed recovery, iOS/Android link handling, QR handoff for desktop where NFC isn't possible. Data-sharing 2FA moved from app push + PIN to email OTP. Dropping the app eliminated a five-figure monthly infrastructure cost.

eID now runs through the official government client (AusweisApp Bund) on every platform — iOS/Android link handling, QR handoff for desktop.

The trade-off, made with eyes open.

Email OTP is a measured reduction in authentication strength — aligned with the security team, justified by proportionality: the stored-identity wallet was scoped to non-regulated use cases and the shared-data volume had dropped, so the risk surface the second factor protects had shrunk materially. Legal confirmed email OTP acceptable for identity-data sharing under GDPR. Documented starting point; authenticator app planned next; SMS available for partners who fund it. A conscious, bounded weakness — not an unexamined default.

Data-sharing 2FA simplified from in-app push + PIN to email OTP — a deliberate, scoped tradeoff.

Defined the KPI framework.

No measurement existed for the redesigned flow. I defined primary metrics (conversion, drop-off by step, verifications per user), secondary (support volume by category, method mix, session length), plus data sources and baseline periods — the instrument that makes post-launch results attributable to specific decisions.

What changed

Two infrastructure changes shipped and went live: the proprietary app was replaced by the government eID client (AusweisApp Bund) on all platforms, and data-sharing 2FA moved to email OTP — eliminating a five-figure monthly cost.

The broader flow redesign — one unified flow replacing the multi-state system, login removed from the entry point with account creation optional at the exit, and all identification methods under a single selector — was completed and approved for release; the company wound down before go-live. Alongside it, system knowledge was documented in one coherent place for the first time, and a measurement framework was defined to attribute results to specific decisions.

The redesigned flow end to end. Login is gone from the entry point; account creation sits at the exit, optional.

Ident method selector

Method selection is now the first action, not a login — one entry point for every user, with identification offered as a choice rather than a gate.

Email-OTP entry

The second factor, right-sized: a one-time code by email replaces the in-app push and PIN — no proprietary app required.

Desktop → QR handoff

A desktop can't read an ID chip, so the flow hands off to the phone by QR — the cross-platform constraint, resolved in a single screen.

What I'd do differently

I scoped identification methods before I had partner integration requirements in front of me. One method was removed early, then reinstated when a partner objected — work a two-week requirements pass would have avoided. In a system where partner contracts constrain the flow, integration requirements are a design input on day one, not a validation step.

Holding the full picture

Complex regulated systems don't fail because of bad design; they fail because nobody is holding the full picture. My contribution was structural: the horizontal layer connecting users, regulation, engineering, partners and cost into decisions that could actually ship .