UX Patterns Guide
Back to compare picker

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

Use name entry when the product needs a person's name with name-specific labels, autocomplete, character support, respectful wording, review, and update paths; use text input for ordinary short text, autocomplete for known-record resolution, select only for finite non-name choices, inline validation for local correction, and error summary for failed submitted forms.

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

Match the interaction to the person's task

Use name entry when the product needs a person's name with name-specific labels, autocomplete, character support, respectful wording, review, and update paths; use text input for ordinary short text, autocomplete for known-record resolution, select only for finite non-name choices, inline validation for local correction, and error summary for failed submitted forms.

Name entry

Use it when: The product must capture a person's name for display, correspondence, booking, application, payment, account details, identity matching, support, or official records.

Make this state clear: Initial full-name state with visible label, purpose hint, autocomplete name, spellcheck false, and adequate width for long names.

Observe the result: A user enters 小林康宏, optionally adds Yasuhiro Kobayashi as a Latin transcription for staff, and sees both values reviewed separately.

Study the full pattern →

Text input

Use it when: The answer is short and user-authored.

Make this state clear: Empty untouched state with persistent label and optional hint.

Observe the result: A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.

Study the full pattern →

Autocomplete

Use it when: The list is long but values are known.

Make this state clear: Empty input state.

Observe the result: Typing filters suggestions while preserving the exact typed value.

Study the full pattern →

Select

Use it when: The user chooses one option from a moderate known list.

Make this state clear: Closed state with empty option or current selected value.

Observe the result: Users can open, scan, choose one value, and review the selected value after close.

Study the full pattern →

Inline validation

Use it when: A single field has a specific correctable problem.

Make this state clear: Invalid field with preserved user value and adjacent correction text.

Observe the result: Validation appears after blur or submit when it helps correction.

Study the full pattern →

Error summary

Use it when: Form submission can produce one or more errors.

Make this state clear: Failed-submit state with summary visible near the form heading.

Observe the result: After failed submit, focus or reading order makes the summary discoverable before users scan the form.

Study the full pattern →

Practice the judgment: Imagine this situation: A form requires first and last names and blocks users with one-part names or names whose family name appears first. 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 →

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.Expose clear visual states for expanded, focused, highlighted, and selected options.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.Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text.Preserve typed input and make selection reversible before submission.Help the person reach a clear task outcome.Help the person reach a clear task outcome.Move users from the summary to the exact field, group, or first invalid control that needs correction.
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.Error message appears far from the field it describes.Summary and field messages visually disconnected or contradictory.
Good UX A user enters 小林康宏, optionally adds Yasuhiro Kobayashi as a Latin transcription for staff, and sees both values reviewed separately.A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.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 enters van der Waals and the system changes it to Van Der Waals in correspondence.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.The message is a system failure, permission problem, or outage rather than a validation issue.
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.Invalid field with preserved user value and adjacent correction text.Failed-submit state with summary visible near the form heading.
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.Using autocomplete where users expect broad search results.Using select to hide two or three obvious choices that should be compared.Showing field errors before users have interacted with the control.Replacing field-level messages with only a top-level summary.

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 enters van der Waals and the system changes it to Van Der Waals in correspondence.
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
Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text.
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 leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.
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
Expose clear visual states for expanded, focused, highlighted, and selected options.
UX guidance
Preserve typed input and make selection reversible before submission.
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
Using autocomplete where users expect broad search results.

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 the person reach a clear task outcome.
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
Using select to hide two or three obvious choices that should be compared.

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 the person reach a clear task outcome.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Error message appears far from the field it describes.
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
Invalid field with preserved user value and adjacent correction text.
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
Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Summary and field messages visually disconnected or contradictory.
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
The message is a system failure, permission problem, or outage rather than a validation issue.
Required state
Failed-submit state with summary visible near the form heading.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Replacing field-level messages with only a top-level summary.
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.

Saved items