Use confirm phone when a captured phone number must be proven reachable by a text-message or voice security code; use phone number entry for collecting and reviewing the number, confirm email for mailbox-access proof, and two-factor authentication when an enrolled factor protects sign-in or a sensitive action.
Use confirm phone when a captured phone number must be proven reachable by a text-message or voice security code; use phone number entry for collecting and reviewing the number, confirm email for mailbox-access proof, and two-factor authentication when an enrolled factor protects sign-in or a sensitive action.
Practice the judgment: Imagine this situation: The service treats a syntactically plausible phone number as verified phone access. 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 | Confirm phone | Phone number entry | Confirm email | Two-factor authentication | Password reset |
|---|---|---|---|---|---|
| UI or UX | UI + UX - Phone reachability confirmation loop | UI + UX - Callable telephone contact capture field | UI + UX - Mailbox access confirmation loop | UI + UX - Additional-factor challenge and recovery flow | UI + UX - Account recovery and reset-token lifecycle |
| UI guidance | Give each control a clear label and visible state. | Render phone entry as a labelled single-line field with number type in the label or hint, purpose and contact-timing text, type tel, autocomplete tel, field-specific errors, and review of both the user's displayed number and any dialable backend value. | 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 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 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. |
| UX guidance | Use confirm phone only when the service must prove that the user can receive a text-message or voice code at the captured number before relying on it for activation, recovery, notification, or sensitive contact. | Use phone number entry when the product genuinely needs to call, text, verify, route, or recover contact with a user through a phone number. | 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 two-factor authentication when the product needs stronger proof after a password, passkey, SSO return, risk signal, new device, or sensitive action. | 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. |
| Good UI | After account creation, the page says a 5-digit code was sent by text message to 07700 900982, shows the code expiry, accepts pasted digits with one-time-code autocomplete, and offers request-new-code and change-number actions. | An appointment service asks for UK mobile or international phone number, says it will call only if the appointment changes, uses type tel and autocomplete tel, and shows the number for review before saving. | 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 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 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. |
| Bad UI | A service marks a phone number verified because it matches a local number format, before any SMS or voice challenge succeeds. | The phone number is stored as a numeric value and loses a leading zero. | A service blocks a low-risk receipt until the email is confirmed even though the user only needs a one-time copy. | Attackers bypass the prompt through a direct endpoint, cached page, or remembered browser weakness. | Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes. |
| Good UX | The person reaches the intended result with clear feedback. | A user pastes 07700 900 982, sees it preserved, reviews that calls may go to that number, and can choose email instead. | 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 lost the phone, uses a single-use recovery code, receives a notification, and is prompted to add a replacement factor after reauthentication. | 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. |
| Bad UX | Old codes confirm a new or changed phone number incorrectly. | A user enters an extension for a desk phone, but validation strips it and the organization later calls the wrong line. | Old links confirm a new or changed email address incorrectly. | Attackers bypass the prompt through a direct endpoint, cached page, or remembered browser weakness. | Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes. |
| Best fit | A captured phone number must be proven reachable before activation, contact-route reliance, recovery eligibility, phone-number change, or a sensitive action continues. | The product must capture a phone number for calls, texts, support callbacks, appointment changes, recovery, delivery coordination, verification, or contact records. | A user must prove access to a mailbox before account activation, invitation acceptance, recovery eligibility, or sensitive notifications. | A sign-in, new device, risk signal, or sensitive action requires proof beyond the primary credential. | Users need to recover an account because the existing password is forgotten, suspected compromised, or unusable. |
| Avoid when | The product only needs to collect or review a phone number for low-risk contact. | The product only needs a name, label, username, reference, or other short text. | The email is only needed for a low-risk receipt, newsletter, or optional contact route. | The user is only choosing an authentication method on the initial sign-in page. | The user is merely signing in with a known current password or passkey. |
| Required state | Sent-code state with target phone number when safe, channel, purpose, code length, expiry, resend, and change-number or support action. | Initial state with label naming the needed number type, purpose hint, type tel, autocomplete tel, and contact-choice wording. | Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action. | Initial additional-factor challenge with factor name, destination or protected action, and primary account context. | Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in. |
| Accessibility burden | Use a clear heading such as Check your phone and label the code input as a security code or phone confirmation code. | Use a visible label and hint that state the number type, purpose, and any contact timing. | Use a clear heading such as Confirm your email address and show the pending email address as text. | Support paste into one field for codes and avoid multi-field inputs that trap focus or break screen-reader reading order. | Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier. |
| Common misuse | Treating phone-number format validation as proof that the user can receive texts or calls. | Using type number and losing leading zeros or plus signs. | Forcing email confirmation when the service only needs a low-risk contact or receipt address. | Blocking paste or autocomplete for one-time codes. | Confirming whether an email, username, phone number, or account exists. |