Classic memory-capacity numbers don't apply to counting visible options

What it is

A common line of reasoning goes: "an interface shouldn't show more options than some memory-capacity number, or users won't be able to remember them" — and from there, a ceiling gets set on menu item counts, icon counts, or palette colors. This conflates two structurally different situations. A memory-capacity number measures how many independent items a person can hold and reproduce without the stimulus itself in view. A menu sitting on screen keeps every option visible the entire time, from opening it to making a choice. The user isn't "recalling what the options were" — they're scanning options that are already displayed. These two activities don't run through the same capacity-limited mechanism at all.

Why it happens

The capacity limit governs maintaining unseen content in a retrievable state — the maintenance mechanism itself is what's limited. When options stay visible, the screen itself acts as external storage, and the user never needs to actively hold any option in mind — whichever one is needed, they simply look at it, and if it can't be found, they scan again. None of this depends on getting the options "into the head" in the first place. Since the user was never asked to perform the capacity-limited mental act at all, using a number that measures the ceiling on that act to cap the length of an always-visible option list has no causal link to draw on.

Studying it

To judge whether a given capacity number can be used to cap a visible option list, first check the original study's task design: did participants respond from memory after the stimulus disappeared, or did they choose or judge while the stimulus stayed on display? The former is a recall paradigm; the latter is a recognition or visual-search paradigm, and the two produce "ceiling" numbers with entirely different meanings. Recognition tasks typically sustain high accuracy at option counts far beyond the classic memory-capacity figures, and when difficulty does appear, it's driven by longer scan and comparison time, not forgetting.

Where it stops holding

An always-visible list isn't unrelated to memory in every case. If an interface requires a user to view one screen of options, then navigate or page away and make a corresponding choice on the next screen from memory, or requires remembering a path already taken through a multi-level menu in order to return to the same place later without re-scanning, then a genuine recall burden has been reintroduced and is worth assessing on its own terms. But that is a different task structure — it does not, in turn, prove that option count itself is bounded by a memory-capacity number.

Applying it

• Stop citing any version of the classic memory-capacity number to justify a ceiling on menu item counts, icon counts, or palette colors. As long as the options stay visible throughout the choice, that citation applies a recall-experiment conclusion to a recognition task, and it doesn't hold up.
• If a visible list genuinely needs a length ceiling, measure it directly instead: record how long it takes users to find a target item and how often they err, at several different option counts, and set the ceiling from that data rather than from a memory-research number.
• How to check: build several versions of the same interface with different option counts, and plot completion time and error rate against count. Only a version where the curve clearly worsens past some count reveals a real problem, and that problem belongs to search efficiency, not memory capacity.

Related

• Same group: A6.10.2 Menu-item limits come from search cost, not memory · A6.10.3 Citing a capacity finding requires checking the original task type · A6.10.4 The classic capacity number came from an absolute-judgment task on a single dimension, structurally unlike most interface scenarios · A6.10.5 Popular science flattened the number into a universal design rule, detached from its original conditions · A6.10.6 Design limits on password length or color count that borrow this number lack empirical support · A6.10.7 Deciding whether a design limit should invoke memory capacity requires first confirming the user is really doing unprompted recall
• Nearby: A6.02 Working memory capacity · A6.05 Recognition over recall
• Search terms: magical number seven misuse · recognition versus recall · menu length