| UI or UX | UI + UX - Additional-factor challenge and recovery flow | UI + UX - Returning-account authentication and session start flow | UI + UX - Credential-verification attempt lifecycle and login outcome handling | UI + UX - Account recovery and reset-token lifecycle | UI + UX - Authentication secret entry control |
| UI guidance | Render two-factor authentication as a focused additional-factor challenge with factor name, destination or protected action, delivery hint, code or approval input, resend timing, alternate factor, recovery-code route, trusted-device choice, and safe failure handling. | 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 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 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 password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input. |
| UX guidance | Use two-factor authentication when the product needs stronger proof after a password, passkey, SSO return, risk signal, new device, or sensitive action. | 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 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 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 password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership. |
| Good UI | A code screen says Enter the 6-digit code from your authenticator app to continue to payroll settings, uses autocomplete one-time-code, shows Try another method, and explains recovery codes. | 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. | 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 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. | A sign-in form has Email and Password fields, the password field uses autocomplete current-password, a Show button, no spellcheck, and an account-details error after failed login. |
| Bad UI | A page says Security check with one empty field, no factor label, no resend timing, and no recovery route. | 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. | The page says Password wrong for one email and No account found for another. | The reset page says No account found for one email and Reset email sent for another. | A login form uses a normal text field named Password and leaves the secret visible on screen. |
| Good UX | A user signs in from a new laptop, enters a code from an authenticator app, chooses not to trust the shared browser, and lands back on the requested workspace. | 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 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 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 pastes a generated password from a password manager, toggles Show to inspect one character, hides it again, and signs in without the value appearing later in review or history. |
| Bad UX | A user never receives an SMS code and can only keep pressing resend with no wait time, no alternate factor, and no support path. | A user signs in from checkout and lands on a generic account dashboard, losing the cart and payment context. | A user gets locked out after repeated typos with no warning and no explanation of when to retry. | A user mistypes their email and the form confirms the account does not exist, exposing account registration status. | A user cannot paste from a password manager and shortens the password to something easier to type. |
| Best fit | A sign-in, new device, risk signal, or sensitive action requires proof beyond the primary credential. | Users need to access an existing account or protected destination. | Users have submitted credentials or authenticator output and need a safe verification result. | Users need to recover an account because the existing password is forgotten, suspected compromised, or unusable. | The user needs to enter an existing password, passphrase, or PIN-like memorized secret. |
| Avoid when | The user is only choosing an authentication method on the initial sign-in page. | The user is creating a new account, choosing a new password, or verifying a new contact method. | The problem is choosing an authentication method or explaining why authentication is required before credentials are submitted. | The user is merely signing in with a known current password or passkey. | The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note. |
| Required state | Initial additional-factor challenge with factor name, destination or protected action, and primary account context. | Initial sign-in state with service or destination context. | Ready-to-submit login state with chosen identifier and authenticator route. | Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in. | Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control. |
| Accessibility burden | Use a clear heading and label that names the factor and does not rely on placeholder-only code fields. | Use explicit labels for identifier, password, passkey, SSO, and one-time-code controls rather than placeholder-only prompts. | Announce verifying, failed-login, throttled, lockout, and success states without forcing focus away from the next useful action. | Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier. | Use a visible label that names the password purpose, such as Password or Current password. |
| Common misuse | Showing a code field with no factor label, destination, expiry, resend timing, or alternate method. | Using account-specific error messages that reveal whether an identifier exists. | Returning different messages for unknown account, wrong password, disabled account, or locked account. | Confirming whether an email, username, phone number, or account exists. | Using type text for passwords. |