Too many items in a group should become another control, not a longer row

What it is

A button group works by showing several keys at once. Add items and the row either starves each key or scrolls sideways out of view. Neither is still a button group. Overflow should become a select menu, a list, or a More, not an ever-longer group. The group’s power is “compare these at a glance,” not “be a scrollable toolstrip.”

Why it happens

Co-visibility is the perceptual premise. Past working memory and viewport width, people must scroll to see the whole set, exclusive relations no longer hold in one glance, and omissions and double picks appear. Keys get skinny, type truncates, hit regions drop, neighbor misses rise. Hick’s choice gets more expensive: the group lays N candidates out as equals, and past seven or eight, search-plus-decision is slower than a filterable menu. Horizontal scrolling also fights the page’s vertical scroll. Products keep stretching the group because “these are peer actions,” and peerhood becomes “none of them can be read.”

Studying it

Build the same actions as 3, 5, 8, and 12-item groups, versus a 5-item group plus a menu for the rest. The task is to find and fire a less common item in the middle.

Independent variables: visible count, horizontal scroll allowed, label length. Dependent variables: time to the target, truncation confusions, sideways scrolling and misses.

A wide lab display underestimates. On a target phone width an 8-item group is often already broken.

Where it stops holding

Pro color or timeline tools can use a scrollable strip; that is an expert workspace and people expect to cruise it. Very high-consensus icon-only view switches (list / grid / board) can carry a few more. A count that grows with data (one key per account) almost always wants a list rather than a group that grows with the data.

Applying it

• Cap co-visible items at a glanceable number (usually four or five); put the rest in a menu or a separate page.
• Do not add horizontal scrolling and still call it a group; the moment it scrolls, change control.
• If count grows with data, start with a list or a picker.
• Verify on the target narrow width: every item’s type is fully visible and hittable. An ellipsis, side arrows, or a required horizontal swipe means it is time to change control.

Related

• Within the group: E1.14.1 A button group presents related actions that are exclusive or parallel · 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
• Adjacent: B1.04 Hick–Hyman law · E3.05 Select menus · E1.15 Button width and flex
• Search terms: button group overflow · Hick's law · too many segments