| UI or UX | UI + UX - Mailbox access confirmation loop | UI + UX - Contactable email address capture field | UI + UX - Persistent account establishment flow | UI + UX - Account recovery and reset-token lifecycle | UI + UX - Additional-factor challenge and recovery flow |
| UI guidance | Render confirm email as a mailbox-access proof loop with the target address, sent-message status, link or code instructions, expiry, resend timing, change-address route, pending or verified state, and clear blocking or non-blocking behavior. | 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. | Render account creation as a focused task with a clear reason for the account, one identifier path, new-credential fields, verification or activation state, existing-account route, and post-creation destination. | 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 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. |
| UX guidance | Use confirm email when the service must know that the user can access the mailbox before activating an account, enabling recovery, sending sensitive notifications, accepting an invitation, or relying on the address for future access. | 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. | Use account creation only when a persistent account is necessary for repeated access, saved data, updates, security, or legal accountability. | 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 two-factor authentication when the product needs stronger proof after a password, passkey, SSO return, risk signal, new device, or sensitive action. |
| Good UI | After account creation, the page says We sent a confirmation link to maya@example.com, explains the link expires in 30 minutes, offers Resend email and Change email address, and returns to the draft after verification. | 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. | A service lets users draft an application, then asks them to create an account to save and return later with email, new password, terms acknowledgement, and a clear activation message. | 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 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. |
| Bad UI | The page says Check your inbox but hides which email address was used and has no resend or change-address action. | A form uses a plain text field named Contact and later rejects it as not email-shaped after submit. | A checkout asks for account registration before showing shipping cost or guest checkout even though the purchase can complete without an account. | The reset page says No account found for one email and Reset email sent for another. | A page says Security check with one empty field, no factor label, no resend timing, and no recovery route. |
| Good UX | A user mistypes the address, notices the pending address on the confirmation page, changes it, receives a fresh link, and continues from the same account-activation step. | A user pastes alex+receipts@example.co.uk, sees it preserved exactly, reviews it on the check page, and changes it only if needed. | A user completes most of a one-hour permit application, chooses to save progress, creates an account using the email already entered, verifies the email, and returns to the same draft. | 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 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. |
| Bad UX | A user never receives the activation email and cannot resend, change the address, or continue in a limited pending state. | A user with a long work address cannot see enough of it to spot a typo before the service sends a reset link. | A user must create an account before learning whether the service is suitable, then abandons because registration feels unnecessary. | A user mistypes their email and the form confirms the account does not exist, exposing account registration status. | A user never receives an SMS code and can only keep pressing resend with no wait time, no alternate factor, and no support path. |
| Best fit | A user must prove access to a mailbox before account activation, invitation acceptance, recovery eligibility, or sensitive notifications. | The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification. | Users need to save and resume drafts, regularly update their data, manage records, check ongoing status, collaborate, or protect repeated access. | Users need to recover an account because the existing password is forgotten, suspected compromised, or unusable. | A sign-in, new device, risk signal, or sensitive action requires proof beyond the primary credential. |
| Avoid when | The email is only needed for a low-risk receipt, newsletter, or optional contact route. | The value is a username, label, reference, organization name, or other short text that may not be an email address. | The task is a one-off transaction that can be completed with a reference number, receipt, guest route, or emailed status link. | The user is merely signing in with a known current password or passkey. | The user is only choosing an authentication method on the initial sign-in page. |
| Required state | Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action. | Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width. | Need-for-account state explaining why an account is required or beneficial at this point. | Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in. | Initial additional-factor challenge with factor name, destination or protected action, and primary account context. |
| Accessibility burden | Use a clear heading such as Confirm your email address and show the pending email address as text. | Use a visible label that names the value as an email address and a hint that explains why it is requested. | Use a clear H1 such as Create an account and visible labels that say Create a password or Email address rather than ambiguous credential labels. | Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier. | Use a clear heading and label that names the factor and does not rely on placeholder-only code fields. |
| Common misuse | Forcing email confirmation when the service only needs a low-risk contact or receipt address. | Using a plain text input without email autocomplete or email keyboard support. | Forcing accounts before users can evaluate a service or complete a one-off transaction. | Confirming whether an email, username, phone number, or account exists. | Showing a code field with no factor label, destination, expiry, resend timing, or alternate method. |