A button group presents related actions that are exclusive or parallel

What it is

A button group welds several actions into one row that shares an outline or dividers, rather than scattering independent buttons. It fits exclusive or parallel related actions: align left / center / right are exclusive; bold / italic / underline are parallel formatting; view modes are exclusive. Unrelated Save and Delete should not be welded because “both have to appear.” The group says “these actions belong to one decision,” not “save a little gap.”

Why it happens

A shared outline triggers perceptual grouping: in-group options are answers to one question, out-group is another matter. When exclusive, the group also implies “pick one,” often with a steady state that can light only one item. When parallel, it implies “several may be on,” but they should still belong to one object (this text’s formatting), not weld document-level Save to paragraph-level format. A wrong group creates a false exclusive: Save and Save as in an exclusive group makes people think they must pick one and lose the other. Scattered related actions do the opposite: people cannot find “the other half” and assume the function is missing. Groups cost width and neighbor misses, so relatedness has to hold first.

Studying it

Lay out the same actions welded versus independent. Tasks: “switch to list view,” “bold and italic together.” Watch for “I thought I could pick only one” and “I didn’t see Center.”

Independent variables: shared outline or not, whether the actions are truly exclusive, count inside the group. Dependent variables: exclusive misreads, missed related items, neighbor misses.

Mixing a choice control (segmented value) with an action group in one experiment scrambles role. Action-group trials should execute, not only change a filter value.

Where it stops holding

Filter chips and segmented pickers are selection controls, not action groups, even when they look similar. Independent toolbar buttons separated by a divider are not a group: no shared outline, no exclusive implication. Two unrelated actions (OK / Cancel) should stay independent, not fake a family of capabilities.

Applying it

• Ask whether the actions are one class of decision on one object; only then share an outline.
• Exclusive groups should light only one item; parallel groups may light several, and the hint should say multi-select.
• Do not put Save with Delete, or navigation with submit, in one group.
• Verify by covering labels: “are these ways of doing the same kind of thing?” “No” but welded, or “yes” but scattered, means grouping is wrong.

Related

• Within the group: E1.14.2 A split button separates default and overflow onto body and chevron · E1.14.3 A too-small chevron on a split button misses into the menu · E1.14.4 Too many items in a group should become another control, not a longer row
• Adjacent: E3.07 Segmented controls · E1.12 Toggle and state buttons · A2 Perceptual organization (Gestalt)
• Search terms: button group · segmented actions · mutual exclusion