Back to compare picker

Action menu vs Menu button vs Button group vs Command palette

Use an action menu for a contextual list of commands on one resource or selection, a menu button for the trigger and popup mechanics, a button group for a few visible peer commands, and a command palette for broad searchable command discovery.

Learn the decision

Match the interaction to the person's task

Use an action menu for a contextual list of commands on one resource or selection, a menu button for the trigger and popup mechanics, a button group for a few visible peer commands, and a command palette for broad searchable command discovery.

Action menu

Use it when: A resource, row, card, selected set, or local page object has several contextual commands.

Make this state clear: Closed trigger or contextual entry point with resource scope.

Observe the result: A user opens Customer actions, chooses Duplicate customer, and receives status that names the customer and keeps focus anchored to the action context.

Study the full pattern →

Menu button

Use it when: A local object or toolbar has three to eight secondary commands.

Make this state clear: Closed trigger state with visible or accessible name.

Observe the result: A user opens Report actions, arrows to Duplicate report, activates it, and focus returns to the Report actions trigger with a status update.

Study the full pattern →

Button group

Use it when: A form, dialog, panel, card, or workflow footer needs two to four related visible commands.

Make this state clear: Default group with a clear label or surrounding context.

Observe the result: A user chooses Reset changes from a separated danger action and receives a clear reset result instead of accidentally resetting beside Continue.

Study the full pattern →

Command palette

Use it when: Users need to traverse a broad product surface quickly.

Make this state clear: Closed state with discoverable trigger.

Observe the result: Keyboard shortcut or visible trigger opens the palette, focus lands in the command input, arrows move the active row, and Enter activates the highlighted safe command.

Study the full pattern →

Practice the judgment: Imagine this situation: The menu mixes commands, filters, navigation links, settings toggles, and editable fields in one list. 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 Action menuMenu buttonButton groupCommand palette
UI or UX UI + UX - Contextual command list for a resource or selectionUI + UX - Button-controlled popup menu of actions or linksUI + UX - Grouped visible action buttonsUI + UX - Modal command surface
UI guidance Render a compact menu of verb-led actions scoped to one resource, row, card, selected set, or page object, with clear section headings, object-aware labels, disabled reasons, and separated dangerous commands.Render a named button trigger, visible opened state, controlled popup, menu items, active item styling, disabled item state, separator or section grouping, and a safe way to distinguish destructive commands.Render a small group of visibly related action buttons with one clear scope, one dominant primary action when needed, lower-emphasis alternatives, consistent labels, visible focus, and stable spacing.Render a compact dialog-like command surface with a search input, current scope, typed command mode, active result, command metadata, and empty state.
UX guidance Make the current object or selection count explicit, update actions when scope changes, and route destructive or privacy-sensitive commands into confirmation, undo, restore, or review instead of running silently.Make dismissal, activation, focus return, unavailable actions, and high-risk command handoff predictable so the menu behaves like a command chooser rather than a hidden form.Use a button group when users need to choose between a few related commands at the same workflow moment, such as saving, continuing, going back, cancelling, applying, resetting, or exporting in one local task.Accelerate expert navigation and repeated actions across a large product while preserving ordinary navigation for novice and low-frequency users.
Good UI A Customer actions menu has Manage customer, Data requests, and Account risk sections, with Edit customer, Merge customer, Request data export, and Delete customer separated at the end.A table row has a Report actions button that opens a compact menu with Open, Rename, Duplicate, Archive, and an unavailable Export item.A form footer shows Save draft, Continue, and Cancel as one named action group, with Continue primary only after required work is saved.Centered command surface with input, shortcut hint, scope chip, grouped commands, command type labels, and a visible active row.
Bad UI Safe, risky, disabled, external, and value-selection items share the same style and role.A primary Save action is hidden behind More while lower-priority icons remain visible.A footer contains Save, Continue, Delete, Help, View report, and Open settings as identical primary buttons.Huge branded modal that buries the input below decorative content.
Good UX A user opens Customer actions, chooses Duplicate customer, and receives status that names the customer and keeps focus anchored to the action context.A user opens Report actions, arrows to Duplicate report, activates it, and focus returns to the Report actions trigger with a status update.A user chooses Reset changes from a separated danger action and receives a clear reset result instead of accidentally resetting beside Continue.Keyboard shortcut or visible trigger opens the palette, focus lands in the command input, arrows move the active row, and Enter activates the highlighted safe command.
Bad UX A user activates a menu item that looks like a command but navigates away and loses unsaved context.A user tabs into a menu and lands in a text input because the menu contains unrelated form controls.Users hesitate because Save, Submit, Continue, and Next are all high-emphasis buttons in the same group.Palette is the only way to reach important navigation.
Best fit A resource, row, card, selected set, or local page object has several contextual commands.A local object or toolbar has three to eight secondary commands.A form, dialog, panel, card, or workflow footer needs two to four related visible commands.Users need to traverse a broad product surface quickly.
Avoid when Only one or two commands are needed and visible buttons would be faster.The job is choosing a form value, selecting several values, or browsing a long list.The controls are mutually exclusive view modes that need a selected state.The app has only a few obvious actions.
Required state Closed trigger or contextual entry point with resource scope.Closed trigger state with visible or accessible name.Default group with a clear label or surrounding context.Closed state with discoverable trigger.
Accessibility burden Give the trigger or menu an accessible name that includes the resource or selected-set scope.Use an actual button for the trigger when possible.Use native button elements for actions so Enter and Space activation, disabled behavior, and focus work predictably.Use dialog semantics with a clear name and modal behavior when the rest of the page is inert.
Common misuse Letting a bulk action menu run single-object commands against multiple selected items.Using a menu button for long value selection that should be a select, listbox, combobox, or multi-select.Putting unrelated actions into one row because the layout has space.Hiding basic navigation behind a keyboard-only palette.

Action menu

UI or UX
UI + UX - Contextual command list for a resource or selection
UI guidance
Render a compact menu of verb-led actions scoped to one resource, row, card, selected set, or page object, with clear section headings, object-aware labels, disabled reasons, and separated dangerous commands.
UX guidance
Make the current object or selection count explicit, update actions when scope changes, and route destructive or privacy-sensitive commands into confirmation, undo, restore, or review instead of running silently.
Good UI
A Customer actions menu has Manage customer, Data requests, and Account risk sections, with Edit customer, Merge customer, Request data export, and Delete customer separated at the end.
Bad UI
Safe, risky, disabled, external, and value-selection items share the same style and role.
Good UX
A user opens Customer actions, chooses Duplicate customer, and receives status that names the customer and keeps focus anchored to the action context.
Bad UX
A user activates a menu item that looks like a command but navigates away and loses unsaved context.
Best fit
A resource, row, card, selected set, or local page object has several contextual commands.
Avoid when
Only one or two commands are needed and visible buttons would be faster.
Required state
Closed trigger or contextual entry point with resource scope.
Accessibility burden
Give the trigger or menu an accessible name that includes the resource or selected-set scope.
Common misuse
Letting a bulk action menu run single-object commands against multiple selected items.

Menu button

UI or UX
UI + UX - Button-controlled popup menu of actions or links
UI guidance
Render a named button trigger, visible opened state, controlled popup, menu items, active item styling, disabled item state, separator or section grouping, and a safe way to distinguish destructive commands.
UX guidance
Make dismissal, activation, focus return, unavailable actions, and high-risk command handoff predictable so the menu behaves like a command chooser rather than a hidden form.
Good UI
A table row has a Report actions button that opens a compact menu with Open, Rename, Duplicate, Archive, and an unavailable Export item.
Bad UI
A primary Save action is hidden behind More while lower-priority icons remain visible.
Good UX
A user opens Report actions, arrows to Duplicate report, activates it, and focus returns to the Report actions trigger with a status update.
Bad UX
A user tabs into a menu and lands in a text input because the menu contains unrelated form controls.
Best fit
A local object or toolbar has three to eight secondary commands.
Avoid when
The job is choosing a form value, selecting several values, or browsing a long list.
Required state
Closed trigger state with visible or accessible name.
Accessibility burden
Use an actual button for the trigger when possible.
Common misuse
Using a menu button for long value selection that should be a select, listbox, combobox, or multi-select.

Button group

UI or UX
UI + UX - Grouped visible action buttons
UI guidance
Render a small group of visibly related action buttons with one clear scope, one dominant primary action when needed, lower-emphasis alternatives, consistent labels, visible focus, and stable spacing.
UX guidance
Use a button group when users need to choose between a few related commands at the same workflow moment, such as saving, continuing, going back, cancelling, applying, resetting, or exporting in one local task.
Good UI
A form footer shows Save draft, Continue, and Cancel as one named action group, with Continue primary only after required work is saved.
Bad UI
A footer contains Save, Continue, Delete, Help, View report, and Open settings as identical primary buttons.
Good UX
A user chooses Reset changes from a separated danger action and receives a clear reset result instead of accidentally resetting beside Continue.
Bad UX
Users hesitate because Save, Submit, Continue, and Next are all high-emphasis buttons in the same group.
Best fit
A form, dialog, panel, card, or workflow footer needs two to four related visible commands.
Avoid when
The controls are mutually exclusive view modes that need a selected state.
Required state
Default group with a clear label or surrounding context.
Accessibility burden
Use native button elements for actions so Enter and Space activation, disabled behavior, and focus work predictably.
Common misuse
Putting unrelated actions into one row because the layout has space.

Command palette

UI or UX
UI + UX - Modal command surface
UI guidance
Render a compact dialog-like command surface with a search input, current scope, typed command mode, active result, command metadata, and empty state.
UX guidance
Accelerate expert navigation and repeated actions across a large product while preserving ordinary navigation for novice and low-frequency users.
Good UI
Centered command surface with input, shortcut hint, scope chip, grouped commands, command type labels, and a visible active row.
Bad UI
Huge branded modal that buries the input below decorative content.
Good UX
Keyboard shortcut or visible trigger opens the palette, focus lands in the command input, arrows move the active row, and Enter activates the highlighted safe command.
Bad UX
Palette is the only way to reach important navigation.
Best fit
Users need to traverse a broad product surface quickly.
Avoid when
The app has only a few obvious actions.
Required state
Closed state with discoverable trigger.
Accessibility burden
Use dialog semantics with a clear name and modal behavior when the rest of the page is inert.
Common misuse
Hiding basic navigation behind a keyboard-only palette.
Decision rules
  • Prefer an action menu when users need a compact contextual command list for one object, row, card, selected set, or page resource, and the menu content needs grouping, disabled reasons, danger separation, or links.
  • Prefer a menu button when the design question is how a trigger opens, labels, focuses, dismisses, and returns focus from the popup rather than how the command list is organized.
  • Prefer a button group when two to four high-value commands should stay visible together because hiding them would slow the task or make the recommended path unclear.
  • Prefer a command palette when commands are product-wide, numerous, searchable, shortcut-driven, or useful across distant contexts instead of tied to the current object.
  • Use action-menu sections when commands have different scopes such as Manage customer, Data requests, and Account risk; do not flatten them into one undifferentiated list.
  • Keep menu item labels verb-led and object-scoped, such as Duplicate customer or Export selected invoices, so repeated menus do not announce identical Open or Delete items.
  • Disable or hide actions according to context: keep unavailable commands visible when the reason teaches capability, but remove commands that can never apply to the selected object.
  • Route destructive action-menu items to confirmation, undo, restore, or typed review when the action is irreversible, externally visible, or privacy-sensitive.
  • Do not use an action menu for choosing submitted field values; use select, listbox, radio group, checkbox group, or multi-select according to the value-selection task.
  • Do not put forms, filters, calendars, sliders, editable tables, or long previews inside an action menu; open a dialog, panel, page, or dedicated editor instead.
Inspect live examples
Failure modes
  • Every row has a More menu containing Open, Open, Open, and Delete with no object names or consequences.
  • The menu mixes commands, filters, navigation links, settings toggles, and editable fields in one list.
  • Bulk selection changes from one item to five items, but the menu still offers single-object commands that will affect the wrong scope.
  • A destructive Delete action appears in the middle of safe commands with the same styling and no confirmation or recovery.
  • Disabled actions are greyed out without reason, so users cannot tell whether permission, selection count, or state blocks them.
  • Primary actions are hidden in an action menu while decorative buttons remain visible.
  • Menu item icons are inconsistent or become the only clue, making action meaning weaker than text labels.
  • A contextual action menu opens from a generic ellipsis with no accessible object scope.

Saved items