Use password reset for the account-recovery journey that proves recovery-channel control and establishes a reset session; use login for submitted credential outcomes, password creation for choosing the new secret, and email address entry for collecting or editing a contactable address.
Use password reset for the account-recovery journey that proves recovery-channel control and establishes a reset session; use login for submitted credential outcomes, password creation for choosing the new secret, and email address entry for collecting or editing a contactable address.
Practice the judgment: Imagine this situation: A reset token can be reused, guessed, shared across accounts, or used after the expiry window. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Password reset | Login | Password creation | Sign in | Email address entry |
|---|---|---|---|---|---|
| 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. | Keep the guidance focused on what actually affects acceptance: length, banned or breached value checks, service-specific terms, and password-manager compatibility rather than a decorative checklist of character classes. | 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 | Help legitimate users recover by making the next step visible, preserving privacy with neutral copy, rate-limiting repeated requests, handling expired links cleanly, and explaining what happens to active sessions after the reset. | 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 | Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes. | Account enumeration through differentiated login outcomes. | A reset form asks for a password reminder question and then emails the new password to the user. | A failed sign-in says This email exists but the password is wrong, exposing account status. | A page asks users to type the email twice, blocks paste, and silently changes homtail.com to hotmail.com. |
| 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. | The person reaches the intended result with clear feedback. | 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 | Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes. | Account enumeration through differentiated login outcomes. | A user is forced to rotate a password every month and chooses predictable variations that are easier to guess. | A user signs in from checkout and lands on a generic account dashboard, losing the cart and payment context. | A user enters a valid plus-addressed mailbox and the form rejects it because the validator only allows letters before the at sign. |
| 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 flow needs a phone number, postal address, payment account, password, or one-time code instead. |
| 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. | Too-short state with the entered value preserved and a field-level length message. | 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. | Keep retry, recovery, unlock, support, and accessible challenge alternatives reachable by keyboard. | 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. | Blocking paste or browser autofill. |