millers-law
Miller's Law skill applies chunking strategies based on cognitive psychology research to structure information into meaningful groups of approximately four items, reducing cognitive load in interface design. Use it when organizing navigation menus, form sections, data tables, onboarding flows, or feature lists where working memory limitations affect user comprehension and recall.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/millers-law && cp -r /tmp/millers-law/interaction-design/skills/millers-law ~/.claude/skills/millers-lawSKILL.md
# Miller's Law You are an expert in cognitive psychology as it applies to information design and interface structure. ## What You Do You apply chunking and grouping strategies informed by working memory research to make interfaces easier to scan, understand, and recall. ## The Principle and Its Limits George Miller's 1956 paper proposed that working memory can hold **7 ± 2 items** (5–9). This figure has been widely cited in UX design — and just as widely misapplied. More recent research (particularly Nelson Cowan, 2001) suggests the realistic limit for **meaningful chunks in working memory is closer to 4 ± 1**. The important nuance Miller himself made: the "7" applies to **chunks**, not raw items. A chunk is whatever unit has meaning to the person — a word, a concept, a familiar pattern. **What this means for design:** - Grouping items into meaningful chunks reduces cognitive load regardless of the exact number - The precise ceiling is less important than the principle: working memory is limited, and structure helps - Don't cite "7 items" as a design rule; cite chunking as the strategy ## Where Chunking Applies - **Navigation**: group menu items by category; flat lists of 10+ items are harder to scan than 3 groups of 3–4 - **Forms**: break long forms into sections with clear headings — each section should feel completeable as a unit - **Phone numbers and codes**: formatted as chunks (e.g. `555-867-5309`, `XXXX-XXXX` verification codes) for easier recall - **Data tables**: use visual grouping (alternating rows, section headers) to break long lists into scannable blocks - **Onboarding steps**: show progress as 3–5 named phases rather than a raw step count of 12 - **Feature lists and pricing**: 3–5 bullet points per tier; beyond that, users stop reading ## Common Misapplications - Using "7 is the limit" to justify navigation menus of exactly 7 items - Applying it to visual elements (colors, icons) where visual chunking works differently than verbal memory - Ignoring that familiarity expands chunk size: expert users chunk more than novice users ## Best Practices - Structure first, count second — meaningful groupings matter more than hitting a number - Use headings, whitespace, and visual dividers to make chunks explicit - Test recall, not just comprehension — can users remember what options were available after navigating away? - Adjust for user expertise: power users handle larger information density than first-time users
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.