Designing against a standard, not a spec
The gap analysis I was handed had open questions where there should have been answers. What started as a Figma task became an architecture decision about how credential types are structured across the entire product.
My role
UX lead, gap analysis, architecture, and Figma design
Timeline
2025, ongoing across quarters
Team context
Cross-functional: VP Products, engineering, QA, external FIDO Alliance UX Working Group
Tools
Figma, FIDO UX Guidelines (passkeycentral.org)
How it started
The document I was handed was half finished
The brief was to pick up an existing FIDO UX gap analysis and take it into design. The document covered the gaps someone else had already spotted. My job was to fill in the Figma and close them out.
Except when I sat down with the live product and the published FIDO UX Guidelines side by side, the document didn't match what was actually there. The analysis had been done against documentation, not the running interface. I found five gaps that hadn't been captured at all, three of them in areas the original document had marked as done.
So before touching Figma, I rebuilt the document from scratch: all 10 FIDO UX principles, the required and optional patterns, the security key patterns, 19 tracked items in total, each with a status, a comment, and an owner. Then I emailed the VP of Products to tell him what I'd found and that the scope was larger than the brief.
The problem
A toggle where a hero should be
The most visible gap was on the Settings page. Where the FIDO guidelines call for a full hero component per credential type, registering a passkey in this product was a toggle. On or off. No explanation, no context. The same page had a security key and a digital credential row alongside it, all three treated as equivalent switches in a list.
The FIDO UX Guidelines are specific about this: each credential type needs its own hero screen with context, a benefit statement, and a clear action before the OS dialog appears. The toggle pattern is exactly what they tell you not to do.
The engineering team had already mocked up a fix: one tabbed component, one panel per credential type. Clean, compact, and wrong for the same reason as the toggle.
The decision
Three independent groups, not one tabbed component
The tab approach fails at the moment it matters most: before the user has registered anything. They're being asked to choose between a passkey, a security key, and a digital credential without understanding what any of them are. Each has a different mental model. A passkey lives on the device. A security key is a physical object. A digital credential is a verified identity document. A tab that changes the header doesn't communicate that distinction.
FIDO Principles 2 and 6 are explicit: each credential type needs its own complete hero treatment. I proposed three separate sections on the page, each with its own hero, add flow, and credential cards. The page gets longer. I named that tradeoff directly when I flagged the structural change to the VP of Products, so there were no surprises in the review.
The same thinking shaped the post-sign-in suggest-registration flow. Rather than showing all options at once, the RP configuration and the user's current credential state determine which single hero appears. One at a time, in a defined priority order. Whatever they haven't set up yet is waiting in Settings.
Outcome
19
Tracked items across all 10 FIDO UX principles, required patterns, optional patterns, and security key patterns, up from 14 in the original document
7
TODOs designed and delivered in Figma, covering registration hero, suggest registration flow, My Profile states, passkey card component, success dialog, and delete warning
1
Architecture decision that changed how credential types are structured across the product, from a flat list to three independent groups aligned with FIDO principles
Reflection
What I'd do differently
I started the Figma work before engineering had resolved the credential type detection question. The nudge logic, which hero variant to show depending on whether the device supports synced or device-bound passkeys, had a dependency on a platform ticket that was still open. I designed for both cases and flagged it. It didn't cause a real problem, but that conversation should have happened before the file was open. Next time I'd push for it earlier.
Gap analysis
Rebuilt gap analysis — all 10 FIDO UX principles, required and optional patterns, 19 tracked items with status and owner
The original state
Toggle — no hero, no context
The existing Settings state — passkey as a toggle, security key and digital credential as flat add rows. Three different credential types, one undifferentiated list.
The architecture decision
Three independent groups — each with its own hero, add action, and credential cards. The structure FIDO Principles 2 and 6 require.
Passkey hero
Registration hero — the full FIDO hero treatment replacing the toggle. Context, benefit, and a clear action before the OS dialog fires.
Suggest registration
Priority logic
Passkeys allowed + user has none → show passkey hero
Has passkey, no security key + allowed → show security key hero
Has both + digital credentials allowed → show digital credential hero
One hero at a time. RP config drives which credential type shows. Settings handles discovery of the rest.
Post-sign-in suggest registration logic — one hero at a time, driven by RP configuration and credential state. No combined dialog, no stacked panels.
Credential card
Passkey credential card — richer metadata than the original list: device name, creation date, last used, sync type, and platform.
FIDO Alliance
FIDO Alliance UX Working Group
Contributing to the 2026 annual plan, gap analysis against published passkey UX guidelines, and rubric development for measuring passkey implementation quality.
Industry contributor · May 2026 — present
FIDO Alliance UX Working Group — the design work connects directly to the standards being written for the industry.