---
title: "Miller's Law"
source: "/reference/millers-law"
description: "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."
---
# 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.
### Principle
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.
### Why it matters
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.
### Deeper design interpretation
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.
### What the agent should reason about
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.
### Common failure patterns
- 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.
### Audit questions
- 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?
### Example agent finding
> **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.
### Agent directive
> 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.
### Apply this when
- Codes, multi-field comparisons, long instructions, step sequences, temporary values, menus without structure, and workflows that hide prior selections.
### Observable signals
- 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.
### Recommended actions
- 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 over-apply
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.
### Example
**Weak:** An agent configuration screen shows a six-character key once, then sends the user to a separate settings page where the key must be retyped from memory.
**Stronger:** The key remains visible with a copy action, and the destination field explains what will happen when it is used.
### Evaluation notes
- **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
### References
- [Laws of UX — Miller's Law](https://lawsofux.com/millers-law/)
- [George A. Miller (1956) — The Magical Number Seven, Plus or Minus Two](https://psychclassics.yorku.ca/Miller/)
## Related rules
- [Working Memory](/__layr/pages/reference/working-memory.md)
- [Chunking](/__layr/pages/reference/chunking.md)
- [Cognitive Load](/__layr/pages/reference/cognitive-load.md)
- [Serial Position Effect](/__layr/pages/reference/serial-position-effect.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Memory & Cognition.
## Retrieve
- Canonical page: https://layr.design/reference/millers-law
- Markdown for agents: https://layr.design/__layr/pages/reference/millers-law.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "millers-law"
title: "Miller's Law"
category: "Memory & Cognition"
origin: established
canonical_url: "https://layr.design/reference/millers-law"
principle: "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."
directive: "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."
applies_when:
- "Codes, multi-field comparisons, long instructions, step sequences, temporary values, menus without structure, and workflows that hide prior selections."
observable_signals:
- "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."
audit_questions:
- "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?"
recommended_actions:
- "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."
avoid_when:
- "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."
common_failure_patterns:
- "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."
evidence_types:
- "Cross-screen dependencies"
- "hidden values"
- "list structure"
- "task instructions"
default_severity: "Medium; high when memory failure causes consequential errors."
typical_confidence: "High for forced recall; low for arbitrary count-based claims."
related_rules:
- { id: "working-memory", title: "Working Memory", url: "https://layr.design/reference/working-memory" }
- { id: "chunking", title: "Chunking", url: "https://layr.design/reference/chunking" }
- { id: "cognitive-load", title: "Cognitive Load", url: "https://layr.design/reference/cognitive-load" }
- { id: "serial-position-effect", title: "Serial Position Effect", url: "https://layr.design/reference/serial-position-effect" }
```
## What to reason about
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.
## Routing
Route a review here when the user must remember, infer, translate, reconcile, or reconstruct information. These rules are especially relevant when the system already possesses context that the interface fails to expose.
## Review procedure
For every finding:
1. Identify the exact component, state, route, or interaction.
2. State the observable evidence.
3. Name the principle that applies.
4. Explain the user consequence in the current context.
5. Estimate severity from the consequence, frequency, and reversibility.
6. Recommend the smallest change that addresses the issue while preserving the product's existing design system.
7. Lower confidence when intent, frequency, audience, device, or product constraints must be inferred.
8. Do not produce generic advice such as "improve hierarchy" or "make this clearer" without specifying what is wrong and why.
## Finding contract — emit exactly this shape
```yaml
finding:
rule_id: string
location: string
evidence:
- observable fact
impact: string
severity: low | medium | high | critical
confidence: low | medium | high
recommendation:
change: string
rationale: string
preserve:
- existing design-system behavior
- valid product constraints
```
## Example finding for this rule
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.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html
Agent setupStep 2 of 2
Step 1 · key createdQ7M-2PXNo longer reachable
→
Step 2 · connect
Connection keyEnter the key you saw earlier
Shown once · required from memory one screen later
```
```html
Agent setupConnect your agent
Connection key
Q7M-2PXCopy
Links every review this agent submits to Acme Studio.