Deciding whether a design limit should invoke memory capacity requires first confirming the user is really doing unprompted recall

What it is

Each misuse covered so far looks different on the surface — applying the number to visible options, ignoring search cost, ignoring the original task type, ignoring popularization drift, ignoring what actually determines passwords and colors — but all of them can be ruled out at once with a single question: in this scenario, is the user actually generating this information from internal memory alone, with no external prompt whatsoever? The moment the answer is no, citing a memory-capacity number is wrong, and there's no need to keep checking it against each specific misuse pattern above.

Why it happens

Memory-capacity numbers describe the ceiling of one specific mechanism: content that isn't in front of the person and has no external record to check against, held entirely in an internal representation while waiting to be retrieved. The capacity number is only relevant when a task genuinely requires running through that mechanism. The moment options are visible, browsing is allowed, or an external record can be consulted, the user is taking a completely different route — recognition, search, comparison — one that never passes through the capacity-limited maintenance step at all, so the capacity number simply has nothing to say about it. This one diagnostic covers every misuse pattern above at once because, whatever form each one takes on the surface, they all share the same underlying mistake: never first checking whether the user was actually being asked to do that thing in the first place.

Where it stops holding

This diagnostic isn't a claim that memory-capacity numbers have no place in design at all — genuine scenarios exist where a user must use information purely from memory with no external prompt whatsoever, such as an operating passcode learned once and never shown again by the system, or needing to recall the exact name of an infrequently used feature from nothing before they can even search for it. These are the scenarios memory-capacity research genuinely speaks to. The diagnostic's job is to filter out the large number of scenarios that don't actually belong to this category, not to deny the relevance of memory-capacity research itself.

Applying it

• Whenever a memory-capacity number is being invoked to justify a design limit, ask three questions first: is the target information visible to the user at the moment of the decision? Is the user allowed to check history, scroll back, or use an external tool? Is the "limit" actually about whether users can hold this content in mind at once, or about whether it can be scanned at a glance? If any answer points to "information is visible," "look-up is allowed," or "this is really a scanning problem," drop the memory-capacity citation and look instead for evidence that actually matches the scenario — visual discriminability, search efficiency, material familiarity, and so on.
• Only when the information is genuinely invisible, the user has no external way to check it, and the answer must be generated purely from internal memory does citing a memory-capacity number make sense at all — and even then, still verify that the cited number's original task type actually matches the current scenario, rather than treating "citation is warranted" as license to apply whatever specific figure comes to hand.
• How to check: run a simple comparison test — in one condition, keep the content to be remembered continuously displayed to the user; in the other, remove the display and require an answer from memory; compare performance across the two. If performance is nearly identical between conditions, the task was never actually testing memory in the first place, and citing memory capacity was never warranted. Only a marked drop in performance once the display is removed confirms this is genuinely a memory-capacity-constrained scenario.

Related

• Same group: A6.10.1 Classic memory-capacity numbers don't apply to counting visible options · 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
• Nearby: A6.05 Recognition over recall · A6.02 Working memory capacity
• Search terms: unaided recall test · recognition versus recall diagnostic · design rule audit