web.dev: Passkey User Experience Design
Google’s web.dev developer site.
License: CC BY 4.0 — same basis as web.dev: Core Web Vitals Business-Impact Case Studies, confirmed via the standard web.dev footer (code samples separately under Apache 2.0).
Key points
- “Designing the user experience of passkeys on Google accounts” documents Google’s own design case study for rolling out passkeys to Google Accounts, organized around two principles held at every step: ease of use and security. Its opening screen leads with a benefit-first header (“Simplify your sign in”) over a security- or technology-first one, since internal testing found convenience — not the underlying technology — was what actually persuaded people; a large primary action invites the person to proceed, “Not now” keeps the choice optional, and “Learn more” serves people who want more detail before committing.
- “Designing the user experience of passkeys on Google accounts” covers building familiarity deliberately: the word “passkey” appears throughout the flow in body copy (not headers), consistently paired with the familiar device actions — fingerprint, face scan, screen lock — that actually trigger it, so people learn the new term by attaching it to something they already understand; and even though a passkey can be satisfied with a device PIN alone, the flow leans into the biometric association anyway because internal research found people perceive biometrics as more secure. It offers deeper technical reassurance (e.g. that biometric data never leaves the person’s own device) behind a “Learn more” link rather than in the primary flow, since testing found only a minority of people cared about that detail up front.
- “Designing the user experience of passkeys on Google accounts” targets when to introduce the option — prioritizing people who already have two-step verification enabled and use the same device regularly, and prompting right after a successful password sign-in specifically because the person is already thinking about their credentials, is confirmed to be on their own device, and has just experienced the exact friction (a sign-in that doesn’t always succeed the first time) a passkey removes. It explicitly positions a passkey as an alternative to a password, not a replacement, since research found many people still want a password kept as a backup — and deliberately avoids language implying passwords are going away. A standalone confirmation page (chosen over a smaller notification or a follow-up email) closes out the creation flow, since testing found people wanted clear closure after their first time setting one up. Falling back away from a passkey is a single “try another way” tap during sign-in.
- “Secure and seamless passkeys: a deployment checklist” is a developer checklist mostly composed of server/API-level implementation items (
excludeCredentials, AAGUID,signalUnknownCredential()) outside scope, but two of its points are pure UX/security-flow guidance independent of any specific API: verify a person with the strongest authentication method already available to them before letting them create a new passkey at all, so an attacker who has merely hijacked a session can’t quietly add their own passkey to the account; and notify the account’s owner whenever a new passkey is created for it, the same way an account would flag a new device or a changed password, in case the creation wasn’t theirs.