skip to content

In a payroll product, how should a multi-select for choosing several of 2,000 cost centres handle search, selected chips and the long list?

level: middleimportance: should knowfreq 42%

answer

  1. nobody scrolls two thousand rows
  2. type to narrow
  3. stay open for the next pick
  4. every chip removable by name
  5. position and total, even virtualised

basics

~20 s

Use a filterable combobox, not a scrolling list: typing narrows the 2,000 options, the popup stays open for more picks, selections show as removable chips with an overflow count, and grouped or virtualised options still report their position and the total.

solid answer

~50 s

At 2,000 options a plain list is unusable, so the multi-select should be a **combobox with filtering**: typing 'Berl' narrows to Berlin cost centres, matching on code, name and owner. The popup stays open after each pick, and selected options carry a visible check mark, not only a colour. Selections appear as **chips** in the field, each with its own remove control named for what it removes, such as 'Remove Finance Berlin', wrapping or collapsing into '+12 more' when there are many. Grouping by region or department and showing recent choices first reduce search effort. If the list is **virtualised**, rendering only the visible rows, each option must still expose its position and the total so screen-reader users know where they are. The Authoring Practices recommend a selection model that needs no modifier keys, and separate Select all and Unselect all controls when those functions matter.

go deeper

for a junior

Know that long lists need search, and that chosen values show as chips each with its own clearly named remove control.

for a middle

Explain the anatomy, why the popup stays open, how grouping and recent items help, and what virtualised options must still expose.

for a senior

Anticipate failures: filtered select-all surprises, destructive Backspace, chips overflowing the layout, and screen readers losing position in a virtualised list.

for a principal

Decide which multi-select variants the system ships, checkbox list versus filterable combobox, with thresholds and one documented selection model.

## Why a plain list fails at 2,000 options A **multi-select** lets people choose several values from a set. For a handful of options, a list of checkboxes is simplest. At 2,000 cost centres, that breaks down: - Scrolling to find one entry among thousands is slow for everyone and exhausting for screen-reader and keyboard users. - People lose track of what they have already chosen when selections are scattered through a long list. - Rendering thousands of rows at once can make the interface sluggish. The component that fits is a **filterable multi-select combobox**: a text input that narrows a popup list of options, with chosen values shown as chips. ## Anatomy | Part | Job | |---|---| | **Input** | Typing filters options by name, code or owner | | **Popup list** | Matching options, each with a visible selected mark | | **Chips** | One per selected value, each with a remove control | | **Overflow indicator** | '+12 more' when chips exceed the space, expandable | | **Clear all** | Removes every selection in one step, ideally with undo | | **Empty state** | 'No cost centres match' as text, not an empty box | ## Chips - Each chip shows enough to identify the value, such as a code and short name. - Each remove control has an accessible name that says what it removes: 'Remove Finance Berlin', not just 'Remove' or an unnamed cross icon. - Chips must not rely on colour alone to show state or category. - When chips exceed the space, collapse to an overflow count that expands on demand, so the field does not grow to fill the screen. - A common convention lets Backspace in an empty input remove the last chip; it speeds experts up but can delete by accident, so pair it with an easy undo or keep it off by default. ## Long lists: search, grouping and virtualisation 1. **Search first.** Match on every identifier people use: code, name, owner. Server-side searching, debouncing and cancelling requests belong to the engineering design of a typeahead, but the spec should say which fields are matched. 2. **Group** options under non-interactive headings such as region or department, so results are scannable. 3. **Surface likely choices**, such as recently used or the employee's current cost centres, above the full list. 4. **Virtualise** long result sets, rendering only rows in view. The Authoring Practices say that when not all options are present because they load as people scroll, each option's position in the set and the set's total size must still be exposed, so assistive technology can say 'item 40 of 2,000'. 5. **Keep option names short and distinct**, avoiding long shared prefixes that screen readers repeat before every option. ## Keyboard and selection model The Authoring Practices describe two multi-select models for a listbox: a **recommended** one where people move with the arrow keys and toggle with Space without holding modifier keys, and an alternative that requires holding Shift or Control while moving to avoid losing selections. The recommended model is easier for most people. The pattern also advises that when selecting or unselecting everything is important, **separate Select All and Unselect All controls** significantly improve accessibility, rather than relying on a hidden shortcut. ## Behaviour details the spec should settle - The popup **stays open** after each selection, since multi-select means more picks are likely; the filter text can be kept or cleared, but the choice must be consistent across the system. - Selections are **committed as they are made**, or on an explicit apply action, the same model everywhere in the form. - Selected options stay visible in the list with their mark, so people can unselect in place. ## Across platforms On phones, a popup with chips under an on-screen keyboard is cramped; native mobile platforms commonly present a full-screen picker with a search field, grouped rows and check marks, then return to a summary row. A cross-platform spec should define the parts, search, selected marks, removable selections, summary with count, and let each platform lay them out.

  • Should selecting 'Select all' with an active filter select all 2,000 cost centres or only the matching ones?
    Only the matching ones, and the label should say so: 'Select all 14 matching'. Selecting 2,000 hidden items from a filtered view surprises people and, in payroll, can spread costs across the wrong centres. Show the resulting count immediately and offer undo.
  • Why not simply use a native multi-select for the cost centres?
    Where a platform offers a native multi-select list at all, it often relies on modifier keys to pick several items, can be cleared by accident with a plain click, shows no summary of what is selected once scrolled, and cannot filter. At a handful of options a checkbox list is better; at thousands, a filterable combobox with chips is.

saying these in an interview costs you the question

  • A scrolling list of 2,000 checkboxes is fine if it is fast enough.
  • A chip's remove button can just be labelled 'Remove' or be an unnamed cross.
  • Virtualised lists only need to expose the rows currently on screen.
  • Holding Control to add each selection is the most accessible model.
  • Select all should always select every item, whatever filter is applied.