The cap is readable width, not memory span
Aliases: Miller myth · 7±2 misuse
What it is
“Navigation cannot exceed seven items” is often sold as a memory-span limit. The cap comes from readable width, not working memory. People do not have to memorise the row before choosing; the names are in front of them, and the path is recognition. What actually stops the count is whether the row can still be read, hit, and pairwise separated. 7±2 describes how many unstructured chunks can be held briefly, not a visible on-screen list.
Why it happens
Miller’s number comes from one-shot recall of unstructured material. Navigation items have labels, icons, and stable places; they remain in view during the choice and do not take that recall channel. People can work in a sidebar of several dozen items by scrolling, grouping, and recognising, not by loading the whole column into working memory. Conversely, five bottom tabs on a narrow phone already cannot fit long labels; the cap is hit by width before five. A wide sidebar can go well past seven and remain usable. Treating 7 as a design constant cuts coverage for no reason in a wide container, and pretends seven will always fit in a narrow one.
Width constraints are physical: type, hit boxes, gaps, language length. Memory barely appears unless the product asks people to glance and then answer after the names vanish — which is no longer navigation, it is a memory test. Experts remembering place use spatial memory and repetition, also not 7±2.
Studying it
Contrast two tasks: pointing with names always visible, and recall after names disappear. Independent variable: item count. In the visible condition, errors should come mainly from crowding and unreadability, not a sudden jump around 7; the vanish condition is where a span-like collapse appears. Put the same items in a narrow tab bar and a wide sidebar; the “collapse point” of visible items should move with container width, not pin at 7.
Texts that cite 7±2 as a navigation rule can themselves be collected as an error pattern — they predict a collapse the width experiment will not show.
Where it stops holding
Briefly flashed menus, or spoken lists with no visual, do use working memory, and then the count needs to be smaller. Asking people to recite a sitemap with no UI measures recall, not navigation. Icon-only items weaken recognition and people start relying on place memory, so count pressure looks more like a memory test — because the labels were removed, not because 7 returned as a constant. For children or under very high cognitive load, working memory is tighter; still look first at whether the row can be read, rather than applying 7.
Applying it
- Lay the real copy out in the target container’s width. If it cannot be read or hit, cut or group. Do not cite 7 and then lay out.
- In a wide container, do not refuse a still-readable entry because “we already have seven”. Decide with scan time and misses, not a memory constant.
- Keep names visible; do not turn navigation into flash-cards that must be remembered before choosing.
- How to check: find, on a narrow screen and a wide one, the count at which reading or hitting starts to fail; the two points should differ. If the team argument is stuck on “is it more than 7”, swap the argument for screenshot legibility and hit boxes. A test that only succeeds after names vanish should not set the cap for visible navigation.