UX Patterns Guide
Back to compare picker

Name entry vs Text input vs Autocomplete vs Select vs Inline validation vs Error summary

Prefer name entry when the value identifies a person, appears in correspondence, profile display, official records, verification, payment, booking, application, or support workflows.

Name entry live exampleText input live exampleAutocomplete live exampleSelect live exampleInline validation live exampleError summary live example

Decision dimensions

Dimension Name entryText inputAutocompleteSelectInline validationError summary
UI or UX UI + UX - Personal-name capture field or field groupUI + UX - Single-line freeform data-entry controlUI + UX - Input widget with suggestion behaviorUI + UX - Single-choice dropdown controlUI + UX - Field-level validation feedbackUI + UX - Form recovery summary
UI guidance Render name entry with a visible label that says exactly which name is needed, such as Full name, name on your passport, given names, family name, previous name, or what should we call you.Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.Render a labeled text field, suggestion popup, highlighted option, selected value, and no-match state.Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance Use name entry when a product must identify, address, verify, correspond with, or officially record a person by name.Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.Help users complete a known value faster without forcing an incorrect suggestion.Help users choose one value from a moderate known list without showing every option permanently.Help users correct a specific field without losing or re-entering the value they already typed.Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI A profile form asks for Full name, uses autocomplete name and spellcheck false, accepts María-José Carreño Quiñones, and shows the exact value before saving.A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.Persistent label, hint text, visible selected value, readable options, and clear required validation state.Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI A form forces Title, First name, Middle initial, and Last name before it knows whether those parts exist or are needed.The only instruction is placeholder text that disappears when the user starts typing.Placeholder-only label that disappears after typing.Placeholder as the only label.Only a red border with no message.Red banner saying fix errors with no links.
Good UX A user enters 小林康宏, optionally adds Yasuhiro Kobayashi as a Latin transcription for staff, and sees both values reviewed separately.A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.Typing filters suggestions while preserving the exact typed value.Users can open, scan, choose one value, and review the selected value after close.Validation appears after blur or submit when it helps correction.After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX A user with one name cannot continue because Last name is required and enters a period just to pass validation.Validation fires on the first focus event and blocks typing before the user has had a chance to answer.Automatically forcing the first suggestion into the field.Hiding two obvious critical choices in a dropdown.Showing errors before users type.Only showing errors below the fold.
Best fit The product must capture a person's name for display, correspondence, booking, application, payment, account details, identity matching, support, or official records.The answer is short and user-authored.The list is long but values are known.The user chooses one option from a moderate known list.A single field has a specific correctable problem.Form submission can produce one or more errors.
Avoid when The product only needs a username, email address, account number, organization name, reference, or anonymous interaction.The answer is a paragraph, comment, address block, or explanation requiring multiple lines.The task is open-ended query exploration.The option set is short and comparison matters.The main recovery task is finding several errors across a submitted page.A single local field issue can be corrected before submit without page-level orientation.
Required state Initial full-name state with visible label, purpose hint, autocomplete name, spellcheck false, and adequate width for long names.Empty untouched state with persistent label and optional hint.Empty input state.Closed state with empty option or current selected value.Neutral field with label, hint, and no error.Neutral form before submit with no summary.
Accessibility burden Use visible labels that state the exact name representation requested.Associate every text input with a visible label or equivalent accessible name that matches the visible question.Expose combobox expanded state, active descendant, and option labels.Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.Expose invalid state on the input and connect error text to the field description where possible.Use a heading and alert behavior that makes the summary discoverable.
Common misuse Requiring first name and last name when a full-name field would work.Using placeholder text as the only label or instruction.Forcing the first suggestion when the user did not choose it.Custom select with no keyboard support or hidden selected state.Showing field errors before users have interacted with the control.Showing a red banner or toast with no links to the invalid answers.

Name entry

UI or UX
UI + UX - Personal-name capture field or field group
UI guidance
Render name entry with a visible label that says exactly which name is needed, such as Full name, name on your passport, given names, family name, previous name, or what should we call you.
UX guidance
Use name entry when a product must identify, address, verify, correspond with, or officially record a person by name.
Good UI
A profile form asks for Full name, uses autocomplete name and spellcheck false, accepts María-José Carreño Quiñones, and shows the exact value before saving.
Bad UI
A form forces Title, First name, Middle initial, and Last name before it knows whether those parts exist or are needed.
Good UX
A user enters 小林康宏, optionally adds Yasuhiro Kobayashi as a Latin transcription for staff, and sees both values reviewed separately.
Bad UX
A user with one name cannot continue because Last name is required and enters a period just to pass validation.
Best fit
The product must capture a person's name for display, correspondence, booking, application, payment, account details, identity matching, support, or official records.
Avoid when
The product only needs a username, email address, account number, organization name, reference, or anonymous interaction.
Required state
Initial full-name state with visible label, purpose hint, autocomplete name, spellcheck false, and adequate width for long names.
Accessibility burden
Use visible labels that state the exact name representation requested.
Common misuse
Requiring first name and last name when a full-name field would work.

Text input

UI or UX
UI + UX - Single-line freeform data-entry control
UI guidance
Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.
UX guidance
Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.
Good UI
A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI
The only instruction is placeholder text that disappears when the user starts typing.
Good UX
A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
Bad UX
Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit
The answer is short and user-authored.
Avoid when
The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state
Empty untouched state with persistent label and optional hint.
Accessibility burden
Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse
Using placeholder text as the only label or instruction.

Autocomplete

UI or UX
UI + UX - Input widget with suggestion behavior
UI guidance
Render a labeled text field, suggestion popup, highlighted option, selected value, and no-match state.
UX guidance
Help users complete a known value faster without forcing an incorrect suggestion.
Good UI
Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.
Bad UI
Placeholder-only label that disappears after typing.
Good UX
Typing filters suggestions while preserving the exact typed value.
Bad UX
Automatically forcing the first suggestion into the field.
Best fit
The list is long but values are known.
Avoid when
The task is open-ended query exploration.
Required state
Empty input state.
Accessibility burden
Expose combobox expanded state, active descendant, and option labels.
Common misuse
Forcing the first suggestion when the user did not choose it.

Select

UI or UX
UI + UX - Single-choice dropdown control
UI guidance
Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance
Help users choose one value from a moderate known list without showing every option permanently.
Good UI
Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI
Placeholder as the only label.
Good UX
Users can open, scan, choose one value, and review the selected value after close.
Bad UX
Hiding two obvious critical choices in a dropdown.
Best fit
The user chooses one option from a moderate known list.
Avoid when
The option set is short and comparison matters.
Required state
Closed state with empty option or current selected value.
Accessibility burden
Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse
Custom select with no keyboard support or hidden selected state.

Inline validation

UI or UX
UI + UX - Field-level validation feedback
UI guidance
Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance
Help users correct a specific field without losing or re-entering the value they already typed.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Only a red border with no message.
Good UX
Validation appears after blur or submit when it helps correction.
Bad UX
Showing errors before users type.
Best fit
A single field has a specific correctable problem.
Avoid when
The main recovery task is finding several errors across a submitted page.
Required state
Neutral field with label, hint, and no error.
Accessibility burden
Expose invalid state on the input and connect error text to the field description where possible.
Common misuse
Showing field errors before users have interacted with the control.

Error summary

UI or UX
UI + UX - Form recovery summary
UI guidance
Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance
Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Red banner saying fix errors with no links.
Good UX
After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX
Only showing errors below the fold.
Best fit
Form submission can produce one or more errors.
Avoid when
A single local field issue can be corrected before submit without page-level orientation.
Required state
Neutral form before submit with no summary.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Showing a red banner or toast with no links to the invalid answers.
Decision rules
  • Prefer name entry when the value identifies a person, appears in correspondence, profile display, official records, verification, payment, booking, application, or support workflows.
  • Prefer text input when the value is a short label, reference, organization name, username, or note that should not receive name-specific labels, autocomplete tokens, or cultural-name handling.
  • Prefer autocomplete when the user must select an existing person record from known identities rather than type a new or changed name.
  • Prefer select for finite non-name choices; do not use a title dropdown unless the title is genuinely required, optional, and cannot be avoided.
  • Prefer a single full-name field when the service can store and use the name as provided, because it avoids false first-name, last-name, middle-name, and title assumptions.
  • Use separate given-name and family-name fields only when downstream systems genuinely need those parts, and then label them clearly with autocomplete given-name and family-name rather than guessing parts from a full name.
  • Use autocomplete name for one full-name field; use honorific-prefix, given-name, additional-name, family-name, honorific-suffix, or nickname only when those parts are deliberately captured.
  • Disable spellcheck and avoid automatic casing changes, ASCII-only filters, or capitalization rules that alter accents, punctuation, spacing, particles, or native-script names.
  • Ask whether you need a common name, preferred form of address, name on official documents, previous name, pronunciation, native-script form, or Latin transcription, and label each need separately.
  • Prefer inline validation inside name entry for missing required name, unsupported script where a real constraint exists, official-document mismatch, or unacceptable characters in a constrained legacy system.
  • Prefer error summary when a submitted application, checkout, account, or identity form has several errors and users need a top-of-form list that links back to the name field.
  • Allow name changes and review the exact spelling before correspondence or official submission, rather than assuming a captured name is permanent.
Inspect live examples
Name entryText inputAutocompleteSelectInline validationError summary
Failure modes
  • A form requires first and last names and blocks users with one-part names or names whose family name appears first.
  • A title dropdown forces users to reveal gender or marital status and still omits valid titles.
  • The field strips accents, apostrophes, hyphens, spaces, or native-script characters from a user's name.
  • A service calls a user by a guessed first token even though they gave a formal full name or a different preferred name.
  • A previous-name field is labelled maiden name and embeds a gendered marriage assumption.
  • A top-of-page error says invalid value without linking back to the name field or preserving the typed name.