| UI or UX | UI + UX - Account recovery and reset-token lifecycle | UI + UX - Credential-verification attempt lifecycle and login outcome handling | UI + UX - New authentication secret selection flow | UI + UX - Returning-account authentication and session start flow | UI + UX - Contactable email address capture field |
| UI guidance | Render password reset as a recovery journey with a neutral request form, reset delivery confirmation, token or code validation, expired and already-used link states, new-password handoff, session cleanup choices, and post-reset notification. | Render login as the outcome-sensitive credential verification state: pending verification, neutral failure, remaining attempts or wait time when policy allows, throttling or lockout state, unlock or recovery route, and successful session-created confirmation. | Render password creation as a labelled new-password field with visible policy guidance, generator and paste compatibility, show and hide control, field-level rejection reasons, and a confirmation state that never displays the accepted secret later. | Render sign in as a focused authentication surface with a clear service or destination name, account identifier field, current-password or passkey path, password-manager-friendly attributes, recovery routes, create-account route, and neutral error area. | Render email entry as a labelled single-line field with purpose text, type email, autocomplete email, spellcheck disabled, enough visible width for review, field-specific errors, and optional typo warning and review states. |
| UX guidance | Use password reset when a user cannot authenticate with the existing password and needs a safe route back into the account without exposing whether the account exists. | Use login when users have already chosen an authentication route and submitted credentials or an authenticator output, and the product must explain the verification result safely. | Use password creation when a user is choosing a new reusable secret during registration, password reset, first-time setup, or password change. | Use sign in when users are returning to an existing account, protected resource, invitation, draft, checkout, or workspace and need to prove control of an authenticator. | Use email address entry when the product must contact the user, identify an account, send a receipt, invite someone, or confirm access to a mailbox. |
| Good UI | A forgot-password page asks for email, then always shows If an account uses this email, we sent reset instructions, with resend timing and a support route. | After a failed login, the page keeps the email address, clears the password, shows Check your details and try again, gives 2 attempts remaining, and keeps forgot password and use passkey routes available. | A signup form labels the field New password, uses autocomplete new-password, allows password-manager generation, says Use at least 15 characters or a generated password, and rejects Password123 because it is commonly used. | A sign-in page names the workspace, shows email or username, password with current-password autocomplete, passkey option, forgot-password link, create-account link, and a destination reminder such as Continue to Q2 budget review. | A receipt form asks for Email address, says We will only use this to send your receipt, uses type email and autocomplete email, and shows a review row before submit. |
| Bad UI | The reset page says No account found for one email and Reset email sent for another. | The page says Password wrong for one email and No account found for another. | A form requires one uppercase letter, one lowercase letter, one number, one symbol, no spaces, and a 12-character maximum while still accepting Summer2026! | A sign-in page has four equal buttons for sign in, create account, reset password, and browse plans, with no indication of the protected destination. | A form uses a plain text field named Contact and later rejects it as not email-shaped after submit. |
| Good UX | A user enters their email, sees a neutral delivery confirmation, opens a time-limited link, creates a new password, chooses to sign out other sessions, and receives a reset notification. | A user mistypes the password twice, sees remaining attempts and a neutral account-details error, uses a passkey instead, and reaches the intended workspace with retry warnings cleared. | A user accepts a password-manager suggestion, pastes it into the field, sees that it meets length and is not in the blocked list, and continues without retyping it. | A user opens a private document link, signs in with a saved passkey, and lands back on the same document with focus near the access confirmation. | A user pastes alex+receipts@example.co.uk, sees it preserved exactly, reviews it on the check page, and changes it only if needed. |
| Bad UX | A user mistypes their email and the form confirms the account does not exist, exposing account registration status. | A user gets locked out after repeated typos with no warning and no explanation of when to retry. | A user enters a strong generated password but the site silently cuts it at 16 characters, so the saved password does not match the password manager. | A user signs in from checkout and lands on a generic account dashboard, losing the cart and payment context. | A user with a long work address cannot see enough of it to spot a typo before the service sends a reset link. |
| Best fit | Users need to recover an account because the existing password is forgotten, suspected compromised, or unusable. | Users have submitted credentials or authenticator output and need a safe verification result. | The user is creating an account with a reusable password. | Users need to access an existing account or protected destination. | The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification. |
| Avoid when | The user is merely signing in with a known current password or passkey. | The problem is choosing an authentication method or explaining why authentication is required before credentials are submitted. | The user is only entering an existing password to sign in or reauthenticate. | The user is creating a new account, choosing a new password, or verifying a new contact method. | The value is a username, label, reference, organization name, or other short text that may not be an email address. |
| Required state | Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in. | Ready-to-submit login state with chosen identifier and authenticator route. | Initial new-password state with purpose, autocomplete new-password, minimum length, paste support, show and hide control, and no character-class checklist. | Initial sign-in state with service or destination context. | Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width. |
| Accessibility burden | Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier. | Announce verifying, failed-login, throttled, lockout, and success states without forcing focus away from the next useful action. | Use a visible label that says New password or Create a password rather than only Password when the user is choosing a new value. | Use explicit labels for identifier, password, passkey, SSO, and one-time-code controls rather than placeholder-only prompts. | Use a visible label that names the value as an email address and a hint that explains why it is requested. |
| Common misuse | Confirming whether an email, username, phone number, or account exists. | Returning different messages for unknown account, wrong password, disabled account, or locked account. | Using uppercase, lowercase, number, and symbol checklists as the main security signal. | Using account-specific error messages that reveal whether an identifier exists. | Using a plain text input without email autocomplete or email keyboard support. |