Miller's Law

Human short-term information processing is limited; the famous 'seven plus or minus two' finding should be treated as historical context, not as a universal UI item limit.

George Miller's 1956 paper discussed limits across several information-processing tasks and introduced chunking as an important mechanism. Modern UX guidance often overextends the number seven into a rigid rule for menu items or navigation. Layr should use the principle as a warning against excessive simultaneous recall, while relying on task context and working-memory evidence rather than an arbitrary item count.

Miller's classic work is frequently reduced to “seven items maximum,” which is too crude for modern interface design. The useful lesson is that unaided short-term processing is limited and that meaningful grouping changes what people can handle. Recognition, familiarity, search, persistence, and chunking can make very large sets easy to use without requiring users to hold them all in memory.

Layr should therefore look for forced recall rather than count visible items. A menu with twelve familiar, grouped options can be easier than a four-step workflow that asks users to remember identifiers, values, and instructions across screens.

The rule becomes most valuable when a task removes context between steps or asks users to keep several unrelated pieces of temporary information active at once.

Identify what information disappears before it is needed again. Distinguish visible choice from remembered choice. If information can be recognized in place, item count alone is weak evidence.

When the interface includes codes, sequences, configuration values, or cross-screen dependencies, prefer persistence and copy/reveal affordances over arbitrary simplification.

• Codes or identifiers are shown once and later requested from memory.
• Multi-step instructions disappear while the task is still in progress.
• Large menus have no grouping or search despite unfamiliar labels.
• Previous selections vanish even though later decisions depend on them.
• Designers justify removing useful options solely because a list exceeds seven items.

• What must the user hold in memory at this moment?
• Is recognition available instead of recall?
• Can related items be chunked meaningfully?
• Is an item-count recommendation supported by task evidence, or only by folklore?

Medium — The setup key must be memorized between steps. The key is displayed once, then hidden when the user navigates to connection settings. Keep the value visible or copyable in the destination step and preserve it until setup completes.

Do not enforce a seven-item limit. Detect interfaces that require users to hold too many independent items in memory at once, and reduce recall through grouping, recognition, persistence, or visible context.

• Codes, multi-field comparisons, long instructions, step sequences, temporary values, menus without structure, and workflows that hide prior selections.

• A user must memorize a code, identifier, value set, or sequence before moving to another screen.
• Several independent instructions must be remembered while completing a task.
• A long list has no grouping, search, labels, or recognition cues.
• The interface clears useful context after each action.

• Keep prior values visible or copyable.
• Group information into meaningful units.
• Prefer recognition through labels, previews, suggestions, and recent items over unaided recall.
• Persist state safely between steps.

Do not flag a menu because it contains eight items. Item count alone is weak evidence. Search, grouping, familiarity, and visual structure can make large sets easy to use.

• Default severity: Medium; high when memory failure causes consequential errors.
• Typical confidence: High for forced recall; low for arbitrary count-based claims.
• Primary evidence: Cross-screen dependencies, hidden values, list structure, task instructions.
• Related rules: Working Memory, Chunking, Cognitive Load, Serial Position Effect