Back to compare picker

Action menu vs Menu button vs Button group vs Command palette

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.

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 Use an action menu when users need several contextual commands without keeping every command visible, and the list itself must explain scope, availability, risk, and outcome.Use a menu button when users need to reveal a short contextual set of commands or links from a single trigger without leaving the current object or toolbar context.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 A More menu contains Open, Edit, View, Delete, Settings, Filter, Owner, and a search box with no sections or object names.An unlabeled ellipsis opens a loose panel of buttons, inputs, links, toggles, and destructive commands with no active item.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 saves a draft, sees Continue become available, then continues without losing the saved status or action hierarchy.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 chooses Delete from a generic row menu and cannot tell whether it deletes the row, account, attached files, or selected customers.A user tabs into a menu and lands in a text input because the menu contains unrelated form controls.A disabled Continue button gives no reason, so the user repeatedly presses Save, Cancel, and Back to find a path forward.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 Treating the action menu as a junk drawer for every command that does not fit elsewhere.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
Use an action menu when users need several contextual commands without keeping every command visible, and the list itself must explain scope, availability, risk, and outcome.
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
A More menu contains Open, Edit, View, Delete, Settings, Filter, Owner, and a search box with no sections or object names.
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 chooses Delete from a generic row menu and cannot tell whether it deletes the row, account, attached files, or selected customers.
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
Treating the action menu as a junk drawer for every command that does not fit elsewhere.

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
Use a menu button when users need to reveal a short contextual set of commands or links from a single trigger without leaving the current object or toolbar context.
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
An unlabeled ellipsis opens a loose panel of buttons, inputs, links, toggles, and destructive commands with no active item.
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 saves a draft, sees Continue become available, then continues without losing the saved status or action hierarchy.
Bad UX
A disabled Continue button gives no reason, so the user repeatedly presses Save, Cancel, and Back to find a path forward.
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.