UX Patterns Guide

Foundation · lesson 3 of 20 · Selection And Choice

Select

Underlying principle: Choice controls express how many options are available, how many may be selected, and when the selection takes effect. The control should reveal the meaning and consequence of each choice.

Choose select sparingly for a single choice from a moderate known list when space or task priority justifies collapsing options.

Start with the decision

Does this fit your task?

The user chooses one option from a moderate known list.

Review the boundary: Compare the task with the alternatives in the decision section.

Review the decision →
Try the live example →Compare alternatives →
Study the interaction

Follow the task before choosing the component

Choice controls express how many options are available, how many may be selected, and when the selection takes effect. The control should reveal the meaning and consequence of each choice.

01 / Recognize the need

What the person is doing

The option set is known, finite, and moderately sized.

02 / Design the response

What the interface must communicate

Choose select sparingly for a single choice from a moderate known list when space or task priority justifies collapsing options.

Closed state with empty option or current selected value.

03 / Judge the outcome

What to look for

Is collapsing this choice worth the extra interaction cost?

The selected value remains visible after the menu closes.

Practice this pattern: Sketch select for this situation: The user chooses one option from a moderate known list. Include this state: Closed state with empty option or current selected value. Review your sketch with this question: Is collapsing this choice worth the extra interaction cost?

Study the Selection And Choice family →Read the underlying principle →
Decision first

Choose this pattern when the problem matches

Use when

  • The user chooses one option from a moderate known list.
  • The selected value matters more than seeing every option constantly.

Avoid when

  • The option set is short and comparison matters.
  • Users need to select many values.
  • The list is long enough that users need search, filtering, or autocomplete.

Problem it prevents

The option set is known, finite, and moderately sized.

Test the behavior

Try strong and weak versions of the interaction

Open the working example, try its controls, and compare the behavior against the decision guidance.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Select in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The option set is known, finite, and moderately sized.

Pattern promise

Choose select sparingly for a single choice from a moderate known list when space or task priority justifies collapsing options.

Required state

Closed state with empty option or current selected value.

Failure to inspect

Inaccessible custom dropdowns.

Access contract

Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Persistent label, hint text, visible selected value, readable options, and clear required validation state.
  • Users can open, scan, choose one value, and review the selected value after close.
  • Very long lists use search or autocomplete instead of forcing scrolling.
Weak implementation

Vague, hidden, hard to recover from

  • Placeholder as the only label.
  • Custom dropdown that looks polished but hides focus and selected state.
  • Hiding two obvious critical choices in a dropdown.
  • Inaccessible custom dropdowns.
UI guidance
  • Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
  • Prefer native select unless custom listbox behavior is truly needed and fully accessible.
UX guidance
  • Help users choose one value from a moderate known list without showing every option permanently.
  • Do not hide short critical choices just to save space, and do not auto-submit while users navigate options.
Implementation contract

What the implementation must handle

States

  • Closed state with empty option or current selected value.
  • Open native option menu or equivalent listbox state.
  • Selected option state after the menu closes.

Interaction

  • The selected value remains visible after the menu closes.

Accessibility

  • Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
  • Keep labels persistent.
  • Associate hints and errors through platform-supported descriptions.
  • Native select follows platform-specific keyboard behavior.

Review

  • Is collapsing this choice worth the extra interaction cost?
  • Would a visible radio group or searchable autocomplete make this list easier to complete?
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System Select component

Government Digital Service - checked

GOV.UK select guidance supports native labels, hints, errors, selected values, long-list caution, and no preselected answers for questions.

U.S. Web Design System Select component

U.S. Web Design System - checked

USWDS select guidance supports sparing use for about seven to 15 options, persistent labels, no auto-submit, and radio/combo-box alternatives.

WAI-ARIA APG Listbox Pattern

W3C Web Accessibility Initiative - checked

APG listbox guidance documents keyboard, labeling, and selected-state requirements for custom listbox-style select alternatives.

Full agent/debug reference

Problem Context

  • The option set is known, finite, and moderately sized.
  • A compact control is justified because visible comparison of every option is less important than saving space.

Selection Rules

  • Choose select sparingly for a single choice from a moderate known list when space or task priority justifies collapsing options.
  • Prefer radio groups for fewer visible choices when comparison or consequence matters.
  • Use autocomplete or combo box behavior when the list is very long, searchable, or hard to scan manually.
  • Do not submit or navigate automatically when the selected option changes.

Required States

  • Closed state with empty option or current selected value.
  • Open native option menu or equivalent listbox state.
  • Selected option state after the menu closes.
  • Required validation error state when no valid option is chosen.

Interaction Contract

  • The selected value remains visible after the menu closes.
  • Opening the control reveals the finite options without accepting arbitrary free text.
  • Changing selection updates local state without automatically submitting the form.
  • A required empty option is not treated as a completed answer.

Implementation Checklist

  • Use native select when platform behavior satisfies the design.
  • Label the control clearly and keep the label visible after a value is selected.
  • Include an empty option only for the no-selection state and validate it as incomplete when required.
  • Provide hint or error text through descriptive associations when needed.
  • Avoid custom selects unless keyboard, focus, selected state, dismissal, and assistive behavior match the native control.

Common Generated-UI Mistakes

  • Custom select with no keyboard support or hidden selected state.
  • Using select to hide two or three obvious choices that should be compared.
  • Placeholder-only labels that disappear after selection.
  • Auto-submitting the form as soon as a user arrows through options.

Critique Questions

  • Is collapsing this choice worth the extra interaction cost?
  • Would a visible radio group or searchable autocomplete make this list easier to complete?
Accessibility
  • Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
  • Keep labels persistent.
  • Associate hints and errors through platform-supported descriptions.
Keyboard Behavior
  • Native select follows platform-specific keyboard behavior.
  • Custom selects must support opening, navigation, selection, and dismissal by keyboard.
  • Do not trigger submission while users are navigating options.
Variants
  • Native select
  • Custom listbox select
  • Grouped select
  • Select with hint and error

Verification

Source trail checked:

Saved items