Design limits on password length or color count that borrow this number lack empirical support

What it is

"Passwords shouldn't be longer than what users can remember," "chart categories shouldn't use more than seven colors," "navigation shouldn't have more than seven items" — these design rules often hang directly off a memory-capacity number as their stated justification, but that justification usually has no matching evidence behind it. What actually sets the practical ceiling in these scenarios is a completely different factor in each case: whether a password is memorable depends on whether it can be organized into a pattern the user already knows, not on whether it currently has to fit into working memory. How many colors a chart can keep visually distinct depends on how discriminable adjacent hues are to the human eye, not on memory capacity. Each of these scenarios has its own directly measurable determinant, and borrowing a number from an entirely different task is really just reaching for a justification that sounds authoritative without actually corresponding to the thing being limited.

Why it happens

A password's memorability is mainly determined by whether the user can organize it into a meaningful structure connected to existing knowledge — a string that breaks into familiar word fragments or habitual combinations is far easier to remember than an equally long, fully random string, and this draws on structure already present in long-term memory. When a user recalls a password, they're retrieving it from long-term memory, not pulling it fresh out of working memory. The ceiling on how many simultaneously displayed colors a chart or interface can keep distinct, meanwhile, depends on the visual system's ability to discriminate adjacent hues and lightness differences — the closer the hues, or the harsher the lighting or display conditions, the fewer colors can be reliably told apart, and this has nothing to do with memory; it's a perceptual-resolution question. What both examples share is that the real limiting factor can be measured directly in each case, while the memory-capacity number is simply being borrowed to lend authority to a rule that should have been grounded in its own evidence instead.

Studying it

Whether a design rule falls into this kind of misuse can be checked by examining its chain of justification: if the evidence cited directly measures the target scenario itself — an empirical study specifically measuring how users create and recall passwords, or a perceptual experiment specifically measuring color discriminability — the rule is grounded. If the chain instead loops back to a generic citation like "because human memory capacity is seven," with no study ever having directly measured passwords or color count themselves, it should be treated as lacking empirical support and in need of scenario-specific verification, not continued use as-is.

Where it stops holding

A specific number happening to land near seven doesn't automatically mean it's a product of this kind of misuse — it could also arise from an entirely different, genuinely relevant reason (a color-discriminability study, for instance, might itself find a safe ceiling near seven). What matters isn't whether the number happens to be seven; it's whether the evidence behind that number came from measuring the scenario itself.

Applying it

• Audit every entry in the current design guidelines that carries a specific numeric ceiling and cites "memory capacity" or similar wording as its rationale, and trace each one's chain of justification to see what evidence it actually rests on. Flag any that lack a study directly measuring that scenario as unverified, and stop treating them as settled rules in the meantime.
• For scenarios like password length or color count, look for or run scenario-specific evidence instead: empirical data on how users actually create and recall passwords for the password case, perceptual test results on hue discriminability or color-blind safety for the color case, and set the ceiling from that data rather than falling back on the memory-capacity number.
• How to check: for every unverified numeric rule, require a study or internal experiment that directly measures that scenario as its backing. For rules that can't produce such evidence, set a provisional ceiling in the product based on current actual data (password-cracking incidence, color mis-identification rate) and mark it explicitly as provisional, rather than keeping the memory-capacity number as a permanent justification.

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.7 Deciding whether a design limit should invoke memory capacity requires first confirming the user is really doing unprompted recall
• Nearby: A1.05 Color vision and opponent-channel mechanisms · O3.01 Password policy
• Search terms: password memorability · color discriminability limit · unsupported design rule