About seven things, plus or minus two.
George Miller's 1956 paper put a number on working memory — about seven chunks. The number itself is fuzzy; the lesson is that memory is small, and the design's job is to group information so users can hold it without strain.
There's a small ceiling to how much a person can hold in working memory at one moment. The trick isn't to shrink interfaces to that ceiling — it's to group information into chunks the user can fit under it.
Miller surveyed studies on pitch perception, taste discrimination, and short-term recall — and the same ceiling kept showing up: about seven items. He never argued this should set menu length; that's a misreading that became gospel.
The way around the limit. Group raw items into meaningful chunks and you fit more in memory. A 10-digit phone number is hard; (555) 867-5309 is easy — three chunks instead of ten digits, and the chunks themselves are familiar shapes.
Even when memory is bounded, recognition is far cheaper than recall. Show the options on screen and let the user point at the right one. Menus, autocomplete, breadcrumbs, recently-used lists, and saved searches are all Miller workarounds dressed as features.
The textbook example. (555) 867-5309 is three chunks; 5558675309 is one ten-digit blur. The same logic applies to credit cards, IBANs, dates, reference numbers, and OTP codes — format for the eye and the memory, not for the database column.
Navigation works best when each level has a small, scannable set. Card-sorting research lands consistently around five to nine categories per level. Beyond that, users start to lose the map of where things sit, and back-tracking spikes.
Show the few choices that matter now, reveal the rest on demand. Settings panels, forms, and onboarding all benefit — keeping any one screen under the working-memory ceiling without hiding what advanced users need a click away.
Long forms collapse into wizards for Miller-shaped reasons. Each step asks for a chunk small enough to hold while deciding — the alternative is a forty-field page where users lose track of what they've already answered halfway down.
"Menus should have at most seven items" — Miller never said this. His work was about chunks in working memory, not interface element counts. Menus are scanned visually, not held in memory. The 7 ± 2 number is a guide to grouping, not a hard ceiling on what's on screen.
The right read: when a user must hold something in mind across a task — a code, a step, a comparison — keep the chunk at five or fewer. When they're scanning with the screen as memory, the limit doesn't apply. Distinguish "carry it" from "see it."
Decades of follow-on research narrowed the figure — Cowan's 2001 paper suggests closer to four chunks for genuine working memory. The principle holds, only sharper: memory is small, expensive, and the design's job is to protect it.
The assistant can hold the chunks a user can't — but the user still has to verify what they couldn't keep in mind themselves.
A model can carry the full set of variables a user can't. "What was that customer's plan?" or "remind me which file we last edited" no longer demands the user keep it in head — the assistant remembers across the session and surfaces it on cue.
When the model handles the chunks the user can't, the user loses the ability to verify. Surface sources, intermediate steps, and undo so people can re-establish ground truth — don't let "I can't hold it all" become "I never had to check."