GitLab needed phishing-resistant login for millions of developers. I designed the MVC and led the full feature — navigating a fundamental product direction question before a single screen was designed.
I designed the original MVC — passkey creation from settings and basic sign-in. When the project expanded, I was assigned to complete the remaining flows: deletion, recovery, device upgrades, and registration during onboarding and sign-in.
Before designing, I identified a critical unanswered question that would shape every flow downstream.
The brief described passkeys as a primary sign-in option — but left open whether passwords would remain. These are fundamentally different products with different risk profiles, recovery models, and error states.
Is passkey an alternative to password — or a replacement? The answer changes everything downstream.
| Consideration | Passkey as Alternative | Passkey Replaces Password |
|---|---|---|
| Account creation | Set password, then offer passkey | Skip password; passkey only |
| Recovery risk | Low — password is fallback | High — lost device = no access |
| MFA + deletion | Password covers MFA gap | Last passkey deleted + MFA enforced = lockout |
| Design scope | Additive flows | Full auth journey reimagined |
Decision: passkeys as primary sign-in alternative, password retained as fallback.
Unified auth management. Password, passkeys, and 2FA consolidated under Account — one place to understand and manage how you sign in.
Safe deletion logic. A gate detects when deleting a passkey would leave a user locked out under enforced MFA, and routes them to enroll another method first.
WebAuthn upgrade path. Identified that existing security key users could upgrade devices to passkeys, giving them both sign-in and 2FA from one device. Designed detection and upgrade flow as an addition to scope.