Phone number entry

Problem Context

• The service may need a phone number for appointment changes, emergency contact, support callbacks, account recovery, SMS codes, delivery calls, two-way contact, or official records.
• Users may have mobile, landline, VoIP, shared, work, international, relay, extension-based, temporary, or no usable phone access.
• Phone-number formats vary by country and may include leading zeros, plus signs, spaces, parentheses, hyphens, extensions, short codes, and local dialing conventions.
• A callable number, SMS-capable number, reachable person, and phone-access-verified number are separate states.
• Phone contact can expose privacy, cost, accessibility, and safety concerns when the service calls or texts without clear consent.

Selection Rules

• Choose phone number entry when the product genuinely needs a telephone route for calls, SMS messages, identity recovery, service contact, delivery coordination, support callbacks, or account verification.
• Do not collect a phone number merely because it is customary; offer another contact route when the user can complete the task without phone contact.
• State whether the field accepts UK, international, mobile, landline, SMS-capable, extension-bearing, or emergency contact numbers.
• Explain why the organization may call or text and when that contact may happen.
• Use type tel and autocomplete tel for one complete phone number, and use component autocomplete tokens only when the design deliberately splits the number into parts.
• Do not use type number, because phone numbers are identifiers and may need leading zeros, plus signs, spaces, parentheses, or extensions.
• Allow paste and familiar local or international formatting, then normalize only for backend routing while keeping the user's displayed value reviewable.
• Avoid input masks unless the accepted number format is narrow, domestic, and proven to exclude international numbers, extensions, and other valid exceptions.
• Validate missing values, too few digits, unsupported country codes, unsupported SMS capability, and extension rules with specific messages next to the field.
• Do not silently rewrite a local number into an international format in the editable field; if a canonical value is stored, show it in review or developer-facing payloads.
• Show the number and contact method on review before saving, calling, texting, or sending a code.
• Use phone or SMS confirmation only when access to that phone must be proven, and include resend, change-number, and alternative-contact paths.

Required States

• Initial state with label naming the needed number type, purpose hint, type tel, autocomplete tel, and contact-choice wording.
• Focused state with telephone keyboard support and normal typing, paste, selection, undo, and correction behavior.
• Familiar-format state preserving spaces, parentheses, hyphens, leading zero, plus sign, and country code in the displayed value.
• International number state accepting plus and country code without a domestic mask.
• Extension state keeping extension or desk-routing instructions separate from the main dialable number.
• Missing required number state with a field-specific error and alternate contact route if phone is not essential.
• Too-short or malformed number state with examples that match the accepted number type.
• Unsupported SMS-capable state when the flow needs text messages but the number or preference may only support voice calls.
• No phone or cannot use phone state that offers email, post, relay, support contact, or manual assistance.
• Reviewed number state showing what will be called or texted and how to change it.
• Confirmation pending state when a code or link has been sent to prove phone access.
• Verified phone access state recorded separately from syntactic validity and dialability.

Interaction Contract

• Users can type, paste, autofill, edit, select, undo, and correct the phone value through native input behavior.
• Submitting an empty or malformed number preserves the typed value and places the correction next to the field or in a linked summary.
• The interface preserves the user's displayed format while the backend derives a separate canonical dialable value when needed.
• Changing the accepted country, contact method, or SMS requirement updates labels, hints, validation, and review copy together.
• Phone entry does not force SMS verification unless the service requires phone access proof and offers change-number, resend, and alternative-contact recovery.
• Review states show the exact value and intended use before phone contact, SMS code, callback, or account recovery is triggered.
• The backend treats format validity, dialability, SMS capability, ownership, and verified access as separate states.

Implementation Checklist

• Decide whether the service needs any phone number, which number types are accepted, and which alternatives are allowed before designing the field.
• Use a native input with type tel, autocomplete tel, a visible label, purpose hint, and aria-describedby for hint, error, and status text.
• Use autocomplete component tokens such as tel-country-code, tel-national, tel-area-code, tel-local, or tel-extension only for intentional split-number designs.
• Preserve leading zeros, plus signs, spaces, hyphens, parentheses, and extension markers in the displayed value.
• Normalize a separate canonical value for backend telephony systems, using international rules such as E.164 only when country context is available.
• Validate on client and server for empty value, too few digits, impossible country code, unsupported extension, and SMS-capability mismatch without rejecting valid familiar formatting.
• Avoid masks and type number; test pasted contact-card values, international numbers, shared phones, landlines, relay numbers, extensions, and users with no phone.
• Provide review, change-number, resend, timeout, and alternative-contact recovery paths for confirmation-code flows.
• Audit privacy, consent, cost, and safety copy for calls and texts, especially when phone contact may reveal sensitive service use.

Common Generated-UI Mistakes

• Using type number and losing leading zeros or plus signs.
• Hard-coding a domestic mask that blocks international numbers or extensions.
• Collecting phone numbers without a genuine service need.
• Failing to explain why the organization may call or text.
• Forcing SMS verification for users with landlines, shared phones, inaccessible devices, or no phone.
• Silently reformatting numbers so users do not recognize what they entered.
• Rejecting pasted values because they include spaces, parentheses, hyphens, or extension text.
• Treating a syntactically plausible number as proof that the user can receive calls or texts.

Critique Questions

• Why does this service need a phone number, and can users choose another contact method?
• Does the label say whether the service needs UK, international, mobile, landline, SMS-capable, or extension-bearing numbers?
• Does the field use type tel and autocomplete tel instead of type number?
• Can users paste and review a number with spaces, plus sign, leading zero, or extension?
• Is the product validating a phone shape, proving dialability, proving SMS capability, or proving access to the device?
• What happens when a user cannot receive SMS or cannot use a phone safely?