UX Patterns Guide
UI + UX Selection And Choice established

Multi-select

Provide a filterable multi-value picker with selected chips or tags, checked options in the open list, removable values, clear-all behavior, and validation that preserves selections.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users choose many values from a long predefined list.
  • The option set benefits from search, grouping, filtering, or async loading.

Avoid when

  • The set is short and independent choices should stay visible.
  • Exactly one option is allowed.
  • Users need to enter arbitrary custom values rather than choose from known options.

Problem it prevents

Users need to choose several predefined values from a list that is too long, searchable, or dynamic for a visible checkbox group.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

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 Multi-select in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The option set may be long, remote, or frequently changing.

Pattern promise

Provide a filterable multi-value picker with selected chips or tags, checked options in the open list, removable values, clear-all behavior, and validation that preserves selections.

Required state

No selected values state with empty selected set.

Recovery path

Selections disappear when the popup closes.

Access contract

Expose selected state for options and labels for remove controls.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Selected values are shown as removable chips or checked rows with clear labels.
  • Search, option list, and selected set are visually distinct.
  • Users can search, add, remove, review, and submit multiple values without losing context.
  • Selection limits and duplicates are handled before submit.
Weak implementation

Vague, hidden, hard to recover from

  • Selected values hidden inside a closed dropdown.
  • Tiny removable chips with unclear labels or close buttons.
  • Removing a value is impossible by keyboard.
  • Remote results overwrite existing selections.
UI guidance
  • Render a filter input, open option list, selected-value chips, remove controls, checked option states, clear-all control, and validation state.
  • Keep selected values reviewable outside the open list so closing or filtering the menu does not hide the selection.
UX guidance
  • Help users choose multiple values from a large, compact, or dynamic option set.
  • Preserve selections while users search, add, remove, clear, and submit.
Implementation contract

What the implementation must handle

States

  • No selected values state with empty selected set.
  • Open filtered option list state.
  • One or more selected values shown outside the option list.
  • Validation state for required, minimum, maximum, duplicate, or unavailable selection.

Interaction

  • Users can search, add, and remove values without losing their current selection.
  • Selected values are visible and removable outside the open option list.
  • The picker communicates selection limits, unavailable choices, duplicate labels, and no-match states.

Accessibility

  • Expose selected state for options and labels for remove controls.
  • Make search input, result list, and selected values relationships clear.
  • Ensure selected chips are reachable and removable by keyboard.
  • Keyboard users can open the list, move through options, toggle selection, and remove selected values.

Review

  • Can users review and remove the selected set before they commit?
  • Does filtering preserve existing selected values when the visible result list changes?
Evidence trail

Source-backed claims behind this guidance

Carbon Design System Dropdown and Multiselect

IBM Carbon Design System - checked

Carbon multiselect guidance supports checkbox options, persistent open menu while selecting, selected-count tags, clear-all behavior, and filtering.

Calcite Design System Combobox component

Esri Calcite Design System - checked

Calcite combobox guidance supports multi-selection, filtering, chip display, chip removal, required validation, select-all, and multiple selection modes.

WAI-ARIA APG Listbox Pattern

W3C Web Accessibility Initiative - checked

APG listbox guidance documents multiple selection states, keyboard navigation, labels, and aria-multiselectable behavior for custom implementations.

Full agent/debug reference

Problem Context

  • The option set may be long, remote, or frequently changing.
  • Users need to search, add, remove, and review multiple values before committing.

Selection Rules

  • Choose multi-select for long, searchable, or compact multi-choice sets where a visible checkbox group would be too large.
  • Show selected values outside the open list as removable chips, tags, or an explicit selected-value summary.
  • Keep the option list open while users select several values unless the platform has a clear equivalent review flow.
  • Use checkbox groups when the set is short enough to scan and should stay fully visible.

Required States

  • No selected values state with empty selected set.
  • Open filtered option list state.
  • One or more selected values shown outside the option list.
  • Validation state for required, minimum, maximum, duplicate, or unavailable selection.

Interaction Contract

  • Users can search, add, and remove values without losing their current selection.
  • Selected values are visible and removable outside the open option list.
  • The picker communicates selection limits, unavailable choices, duplicate labels, and no-match states.

Implementation Checklist

  • Expose selected values as removable chips or an explicit selected-value surface.
  • Show checked state for selected options when the picker list is open.
  • Support filtering or grouping for long lists.
  • Preserve selections on validation failure and during remote result refreshes.
  • Handle duplicate labels with context and avoid custom widgets without listbox or checkbox semantics.

Common Generated-UI Mistakes

  • Hiding selected values inside a closed menu.
  • Using multi-select for one mandatory choice.
  • Building custom widgets without listbox or checkbox semantics.
  • Closing the menu after each selection when users commonly need several values.

Critique Questions

  • Can users review and remove the selected set before they commit?
  • Does filtering preserve existing selected values when the visible result list changes?
Accessibility
  • Expose selected state for options and labels for remove controls.
  • Make search input, result list, and selected values relationships clear.
  • Ensure selected chips are reachable and removable by keyboard.
Keyboard Behavior
  • Keyboard users can open the list, move through options, toggle selection, and remove selected values.
  • Focus order should not trap users inside selected chips.
  • Escape or equivalent dismissal should close the list without clearing selected values.
Variants
  • Filterable checkbox listbox
  • Tag picker
  • Transfer list
  • Grouped multi-select

Verification

Source trail checked:

Saved items