Breadth is capped by how many items can be scanned

What it is

How many items a level may hold is not a question of whether the taxonomy can be cut further. It is a question of whether people can finish a scan and still discriminate inside that piece of navigation. Breadth is capped by the scannable count: beyond it, extra items are not paid for with “one more decision”—they never enter the field of view, or they enter it without enough time for a discrimination. That is a visuo-perceptual and short-horizon search limit, not whether classes are semantically exclusive.

The cap differs for a horizontal bar, a vertical list, and the columns of a mega-menu. The same “eight” may already overflow a bottom tab bar and still be scannable in a sidebar list.

Why it happens

Scanning navigation is visual search, not loading options into 7±2 of short-term memory and recalling them. The eyes jump along an expected axis (left to right on a bar, top to bottom in a list), read a label per jump, and stop on a hit or a give-up. More items, more jumps. The moment an item wraps, falls into overflow, or hides behind “More,” the search space splits and the far segment is not scanned by default. Type size, spacing, and whether labels align in a clean column change how many labels one fixation can cover, so the cap is a layout parameter, not a universal integer.

A mobile viewport presses the scannable count down: a bar becomes a strip that must be swiped, and items swiped away might as well not exist. A desktop mega-menu uses columns to split one search into “pick a column, then a row.” Effective breadth is columns times items per column, but people have to learn the column headings first; otherwise extra columns only zigzag the scan path. Control-level guidance about how many items a widget can hold is a different layer; this cap is how far the depth/breadth tradeoff can go wide.

Studying it

Hold depth fixed and vary only item count and layout at one level; use visual-search measures, not satisfaction.

• Paradigms: menu visual search with target position randomized; eye tracking for whether the scan covers every item; first-click tests when the target sits in overflow.
• Independent variables: item count, orientation (horizontal / vertical / multi-column), whether scrolling or overflow is required, type size and spacing.
• Dependent variables: search time, miss rate (target on screen but never fixated), rate of opening overflow.
• Methodological note: tests that always plant the target in the first few slots will overstate the scannable count. Spread the target uniformly along the whole nav, including after “More.” 7±2 is not a legal cap to use as an independent variable; it does not measure scanning.

Where it stops holding

Icon-plus-short-label tab bars scan even fewer items because each slot is wider and labels compete for width. Experts who know the target’s slot number drive search time toward zero; the cap binds novices and infrequent tasks. Voice, command palettes, and search suggestions match queries; they are not under this visuo-perceptual cap. In languages whose reading direction disagrees with the bar’s direction, rescan along the writing direction; do not import counts from a Latin layout.

Applying it

• Screenshot the nav on the target device at real type size and count items that can be read in full without scrolling or opening overflow. That count is this level’s scannable breadth.
• Items past that count are not still “on this level”: change layout (horizontal to vertical, add a column), or admit they live one level down. Do not hide them in “More” and still advertise full breadth.
• Multi-column layouts need scannable column headings before you add a column.
• Verify by rotating the target through every slot (including overflow) in a first-click test. Where hit rate collapses after a given index, that index is the scannable cap of the current layout—breadth in the tradeoff cannot cross it.

Related

• Within the group: G2.04.1 Each added level costs one more decision and one more wait · G2.04.3 Breadth beats depth when categories are distinctive
• Adjacent: E5.15 Number of navigation items · G2.02 Flat navigation · E5.01 Top app bars
• Search terms: visual search · scannable menu · navigation breadth