skip to content

In a payroll product, why is 'Export payslips' with its format choices an action menu, not a select, and what breaks if swapped?

level: juniorimportance: should knowfreq 46%

answer

  1. a value versus a command
  2. what the closed control shows
  3. can it be required
  4. arrowing through a select
  5. the last action looks like a setting

basics

~20 s

A select holds a value that a form keeps and submits; an action menu runs a command and holds no value. Commands in a select can fire while arrowing and look like saved settings; a menu cannot show or require a value.

solid answer

~50 s

A **select** (or select-only combobox) answers a question: it has a name and a **value**, it can be required, and its closed state shows the current choice, such as 'Pay frequency: Monthly'. An **action menu**, opened by a menu button, offers **commands**: 'Export as spreadsheet', 'Export as document', 'Print'. Per the Authoring Practices, a menu button has a name but no value and cannot be marked required, so it cannot convey a choice once closed. Swapping them breaks both ways. Commands in a select either fire on change, which can trigger while a keyboard user arrows through the options, since moving through a single-select list can change its value, or need a separate Go button; and the last export format then sits in the control looking like a saved setting. A value in a menu leaves nothing visible after choosing and nothing a form can require or submit.

go deeper

for a junior

Know the core split: a select stores and shows a value, an action menu runs commands and stores nothing.

for a middle

Explain why commands in a select misfire for keyboard users and look like state, and why a menu cannot convey or require a value.

for a senior

Audit a product for swapped controls, including 'Go' buttons and resetting selects, and replace them without breaking existing workflows.

for a principal

Name and document select and action menu as distinct components across platforms and design tools, so the confusion cannot be designed in.

## Two compact controls that look alike Both a **select** and an **action menu** are compact controls that open a list. That resemblance is where the confusion starts. They answer different questions: a select asks 'which one?' and remembers the answer; a menu asks 'what should happen?' and does it. | Aspect | Select (or select-only combobox) | Action menu (menu button) | |---|---|---| | Purpose | Choose a **value** | Run a **command** | | Closed control shows | The current value | A fixed label, such as 'Export' | | Has a value | Yes, distinct from its name | No | | Can be required in a form | Yes | No | | Effect of choosing | Stores the choice; the form submits it later | Performs the action immediately | | Payroll example | Pay frequency; tax residence | Export payslips; Print; Duplicate pay run | The Authoring Practices state the difference directly: a menu is a widget offering a list of choices such as actions or functions, and a menu button has an accessible name but no value, so it is not suitable for conveying the user's choice in its collapsed state. ## Commands inside a select - **Accidental firing.** If choosing an option triggers the export, a keyboard user can fire exports while moving through the list; the Authoring Practices note that navigating a single-select listbox immediately changes its value, with no Escape undo. - **A command that looks like state.** After exporting, the control still reads 'Export as document', as though that were a saved preference. - **Re-running is awkward.** Choosing the same command again may not register as a change at all. - **Workarounds pile up.** Teams add a 'Go' button beside the select, or reset it to a placeholder after each action, which confuses everyone further. ## A value inside a menu - **Nothing shows the choice.** After picking 'Monthly' from a menu, the collapsed button still reads 'Pay frequency', so nobody can check the current value. - **It cannot be required or validated** as a form field, and assistive technology hears a button, not a field with a value. - **It invites the wrong expectation**: people expect a menu item to do something right away. ## How to decide 1. Will the choice be **stored and shown** afterwards? Use a select. 2. Does choosing **perform an action now**, with nothing left to show? Use a menu button and menu. 3. Is it a single obvious action? Use a button; a menu of one is noise. 4. Is it a view setting that applies immediately and should stay visible, such as sort order? A select or segmented control that shows its value is usually clearer than a menu. ## Hybrids and how to judge them - **Split button.** A primary action, 'Export payslips', with an attached menu of alternative formats. It is a button plus a menu, not a select: the main part acts, the menu offers other actions. - **Menu with a checked item.** Some interfaces put a view setting, such as density, inside a menu and mark the active item. It works only if the collapsed control also shows the current setting. - **A select with an 'Actions...' placeholder that resets after each use.** This is the classic anti-pattern: it borrows a select's look for a menu's job and inherits the problems of both. The test is always the same question: after the person chooses, is there a value to show and keep, or has something simply happened? ## Payroll examples - **Select:** pay frequency, default payment method, tax code basis, department. - **Menu:** 'Export payslips' with its formats; row actions on a pay run such as 'Duplicate', 'Reopen', 'Delete draft'. - **Button:** 'Approve pay run', because it is a single action with serious consequences and deserves its own visible control. ## Across platforms Native mobile platforms separate the same two ideas: pickers that show a current value, and action sheets or pop-up menus that run commands. A design system should specify them as distinct components with distinct names, so neither a designer in a design editor nor an engineer on any platform can reach for one when they need the other.

  • Where do destructive commands like 'Delete draft pay run' belong in an action menu?
    At the end, separated from routine commands, labelled plainly and styled as destructive, and followed by a confirmation or an undo, because a menu item acts immediately. If the action is common and serious, consider a dedicated button outside the menu so it is never chosen by a slip down the list.
  • Is a sort-order control on a payslip table a select or a menu?
    Usually a select or segmented control, because the sort order is a current state people want to read back, 'Sorted by: Pay date'. A menu that sorts and then shows only 'Sort' hides that state. Some interfaces use a menu with a checked item, but the collapsed control should still show the active sort.

A select is like a thermostat dial: it holds a setting you can read at a glance until you change it. An action menu is like a lift's floor buttons: pressing one makes something happen now and leaves no setting behind.

saying these in an interview costs you the question

  • A select is fine for commands as long as it resets after each action.
  • Menus and selects are interchangeable because both open a list of options.
  • A menu button can be marked required like any other form field.
  • Keyboard users will not trigger actions in a select by accident.
  • The collapsed menu button should change its label to the last item chosen.