Button group

Problem Context

• A form, dialog, card, toolbar section, panel footer, wizard step, or result area has multiple commands that belong to one local task.
• Users must distinguish the recommended next action from alternatives such as save draft, cancel, back, skip, reset, export, or delete.
• The actions are visible commands, not selected values, view modes, or hidden menu items.
• The group must survive mobile stacking, high zoom, keyboard focus, processing states, and disabled dependencies without losing action meaning.

Selection Rules

• Choose a button group when two to four actions are contextually related and should be considered together at one workflow moment.
• Use a segmented control when the buttons represent mutually exclusive modes or views and need a persistent selected state.
• Use a menu button when secondary commands are numerous, lower priority, or contextual enough to hide behind a named trigger.
• Use confirmation dialog after a clearly labelled dangerous action is chosen and the consequence needs review before commitment.
• Use text links or navigation patterns when the controls are destinations rather than commands.
• Avoid placing destructive actions directly beside safe forward actions unless visual separation, wording, confirmation, or undo makes the risk clear.
• Keep one primary action unless the workflow intentionally presents equal choices with no recommended path.
• Move low-frequency or unrelated commands out of the group rather than adding more buttons to a crowded row.

Required States

• Default group with a clear label or surrounding context.
• Primary, secondary, tertiary, and danger visual hierarchy when those roles are present.
• Focused state for each button in source order.
• Hover or pressed state for pointer and touch feedback.
• Disabled or unavailable state with visible reason.
• Processing state after activation that prevents duplicate submission.
• Successful action status that names the command that ran.
• Responsive stacked state preserving action order and readable labels.
• Separated destructive action state.
• Long label and high-zoom state without clipped text.

Interaction Contract

• Each button performs a command immediately or starts a named flow; buttons in the group do not represent persistent selected values unless the component is intentionally a segmented or toggle group.
• The group has one local scope and a programmatic grouping when surrounding context is insufficient.
• Button labels use verbs and objects that match the result message, accessible name, and logged action.
• The primary action is visually dominant only when it is the recommended next action.
• Disabled commands are either temporarily blocked with a reason or removed until relevant.
• Processing actions prevent duplicate activation and announce progress or completion.
• Destructive actions are visually separated, lower-emphasis unless explicitly primary, and routed to confirmation, undo, or clear recovery when needed.
• Keyboard users tab through buttons in the same order that visual layout implies; Enter and Space activate the focused button.
• Responsive stacking keeps safe progression, cancellation, and danger relationships understandable.

Implementation Checklist

• Inventory each command and remove actions that do not share the same local task scope.
• Choose the primary action and make secondary alternatives lower emphasis.
• Place danger actions away from safe forward actions or put them behind confirmation or undo.
• Use real button elements for commands and reserve links for navigation.
• Wrap the group in a list, role group, or toolbar only when that grouping communicates the relationship accurately.
• Keep visible labels, accessible names, icons, and result status aligned.
• Explain disabled states through helper text, inline status, or dependency messaging.
• Prevent duplicate activation during processing and restore the button state after completion or error.
• Test source order, mobile stacking, high zoom, forced colors, focus rings, touch targets, and localization.

Common Generated-UI Mistakes

• Putting unrelated actions into one row because the layout has space.
• Using two or more high-emphasis buttons that compete for the same next step.
• Mixing destructive and non-destructive actions with identical visual weight.
• Using button groups as page navigation or content links.
• Giving command buttons aria-pressed selected state when they are not toggles or modes.
• Disabling the primary button without explaining the unmet condition.
• Replacing text labels with icons at small widths.
• Letting responsive wrapping reorder actions unpredictably.

Critique Questions

• Do all buttons in the group share one local task scope and workflow moment?
• Is the recommended action visually clear without creating two competing primary commands?
• Can users tell why an unavailable command is blocked and what fixes it?
• Are destructive commands separated from safe progression and backed by confirmation, undo, or recovery?
• Will source order, visible order, and keyboard order remain understandable on mobile and at high zoom?