| 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. | 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 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 | A service blocks a low-risk receipt until the email is confirmed even though the user only needs a one-time copy. | A page asks users to type the email twice, blocks paste, and silently changes homtail.com to hotmail.com. | A registration screen has Sign in and Sign up side by side with identical email and password fields, plus newsletter, profile photo, and referral-code fields. | Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes. | Attackers bypass the prompt through a direct endpoint, cached page, or remembered browser weakness. |
| 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 lost the phone, uses a single-use recovery code, receives a notification, and is prompted to add a replacement factor after reauthentication. |
| Bad UX | Old links confirm a new or changed email address incorrectly. | A user enters a valid plus-addressed mailbox and the form rejects it because the validator only allows letters before the at sign. | A user must create an account before learning whether the service is suitable, then abandons because registration feels unnecessary. | Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes. | Attackers bypass the prompt through a direct endpoint, cached page, or remembered browser weakness. |
| 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 flow needs a phone number, postal address, payment account, password, or one-time code instead. | 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. | Support paste into one field for codes and avoid multi-field inputs that trap focus or break screen-reader reading order. |
| Common misuse | Forcing email confirmation when the service only needs a low-risk contact or receipt address. | Blocking paste or browser autofill. | Forcing accounts before users can evaluate a service or complete a one-off transaction. | Confirming whether an email, username, phone number, or account exists. | Blocking paste or autocomplete for one-time codes. |