Name entry

Problem Context

• The service may need a name for account display, correspondence, booking, official records, identity checks, payments, school or health records, support queues, legal documents, search, sorting, or relationship management.
• Users may have one name, multiple given names, multiple family names, patronymics, particles, prefixes, suffixes, titles, nicknames, native-script names, Latin transcriptions, changed names, or names that do not fit first-name and last-name order.
• Some flows need the name a person commonly uses, while others need the exact name on a passport, driving licence, bank account, payment card, court document, or government record.
• Name fields can reveal gender, marital status, family structure, religion, caste, migration history, or gender transition, so unnecessary collection and wording can create harm.
• Downstream systems often pressure teams to split, sort, capitalize, or ASCII-normalize names even when the user-facing service does not need those assumptions.

Selection Rules

• Choose name entry when the product must capture a person's name for identification, correspondence, display, official records, booking, payment, verification, support, or relationship handling.
• Do not ask for a name if the service can work with an account identifier, email address, username, customer number, or anonymous flow instead.
• Use a single Full name field when the service can store and use the name as provided.
• Use split fields only when downstream systems genuinely need separate parts, and then label them as Given names and Family name for international audiences rather than relying on first and last order.
• Make it clear whether the service needs a common name, preferred name, official-document name, billing name, cardholder name, previous name, native-script name, or Latin transcription.
• Use autocomplete name for a full-name field, and use given-name, additional-name, family-name, honorific-prefix, honorific-suffix, or nickname only when deliberately collecting those parts.
• Set spellcheck false and avoid automatic casing, ASCII-only filters, title-case transforms, or stripping punctuation unless a hard external constraint is explained.
• Support long names, one-letter names, single-part names, spaces, hyphens, apostrophes, accents, non-Latin scripts, particles, prefixes, suffixes, numbers, and symbols where the service can store them.
• Avoid asking for title; if unavoidable, use an optional text input rather than a fixed dropdown list.
• Ask What should we call you? when the service wants a form of address instead of guessing a given name from the full name.
• Use Previous name instead of maiden name when asking about earlier names.
• Allow users to change stored names and review exact spelling before correspondence, official submission, or identity matching.

Required States

• Initial full-name state with visible label, purpose hint, autocomplete name, spellcheck false, and adequate width for long names.
• Focused state with normal text editing, paste, undo, selection, browser autofill, and no forced capitalization.
• Accented or punctuation state preserving hyphens, apostrophes, spaces, particles, and case.
• Native-script state accepting non-Latin characters with correct display direction and storage.
• Latin transcription state shown only when the service needs staff recognition, search, or back-office processing.
• Official-document state with wording that asks for the name as shown on the relevant document.
• Preferred address state asking what the service should call the user rather than guessing a name part.
• Previous-name state using neutral wording and making the need clear.
• Missing required name error state with the typed value preserved after correction.
• Unsupported character or legacy-system constraint state that explains the external reason and gives a recovery path.
• Reviewed name state showing the exact spelling, script, preferred address, and change action.
• Name update state for stored personal details.

Interaction Contract

• Users can type, paste, autofill, edit, select, undo, and correct names through native text behavior.
• The interface preserves the entered spelling, case, accents, punctuation, spacing, and script unless a visible external constraint requires a separate representation.
• Submitting an empty or constrained name preserves the typed value and places correction text next to the field or in a linked summary.
• The product never infers title, gender, marital status, family name, sorting key, or preferred address from the entered name without a designed field or confirmation.
• If multiple name representations are needed, each representation has its own label, purpose text, storage field, and review row.
• Users can change stored names without restarting the whole service when the product stores personal details.
• The backend treats display name, official name, preferred address, previous name, native-script name, Latin transcription, and verified identity match as separate states.

Implementation Checklist

• Decide which name representation the service needs and where it will appear before selecting fields.
• Use a native text input with visible labels, stable ids, autocomplete tokens, spellcheck false, and aria-describedby for hints, errors, and status text.
• Prefer autocomplete name for full name; use component tokens only for intentional split fields.
• Store Unicode text and avoid byte-length assumptions; set database, API, export, search, and display paths to preserve long and multi-script names.
• Validate required presence and documented external constraints without rejecting real names because they are short, single-part, long, accented, hyphenated, punctuated, spaced, or non-Latin.
• Avoid title dropdowns, forced middle initials, forced family-name requirements, automatic capitalization, ASCII-only sanitization, and algorithmic name splitting.
• Provide review, change, and update paths for names used in correspondence, official submissions, identity checks, or payment.
• Test screen readers, browser autofill, mobile keyboards, paste, zoom, right-to-left or native-script names, one-letter names, multiple family names, particles, previous names, and name-change flows.

Common Generated-UI Mistakes

• Requiring first name and last name when a full-name field would work.
• Blocking one-part names or one-letter names.
• Using a title dropdown that forces gender or marital-status disclosure.
• Stripping accents, apostrophes, hyphens, spaces, particles, or native-script characters.
• Automatically changing case or capitalization.
• Asking for maiden name instead of previous name.
• Guessing what to call someone from the first token of their full name.
• Treating a name captured for display as proof of legal identity.
• Making middle names required when the service does not need them.
• Storing only split parts and being unable to display the exact name the user provided.

Critique Questions

• Why does the service need this person's name, and where will it be displayed or used?
• Does the label ask for common name, full name, official-document name, previous name, or preferred address?
• Can the field accept long, single-part, one-letter, accented, punctuated, spaced, and native-script names?
• Does the implementation preserve case and spelling exactly as entered?
• Is any split into name parts required by a real downstream use, or is it a storage habit?
• Can users update their name and review exact spelling before correspondence or official submission?