Miller's Law

How many items a menu can hold, or how many steps a signup should take, went unanswered for a long time. Whoever built the screen put in as much as would fit, and whoever used it hesitated in front of the result. People failed to find things in twenty-item menus all the time, but there was no way to tell whether the count was the problem or the labels were.

So the argument turned into a matter of taste. Someone would say the menu felt crowded, someone else would ask how many was the right number, and nobody could answer that. What settled it was volume in the room and the wish to ship one more feature.

In 1956 the psychologist George Miller measured short-term memory and came back with a number: people can keep about seven items in mind at once. Design keeps citing it not because it hands over an exact ceiling but because it was the first evidence that the limit exists in a form anyone can measure. It replaced a question of taste with a different question — can a person carry this?

The place that holds whatever you are working on right now is small, so a new item pushes an older one out. That place is short-term memory. Unlike the memory that accumulates over years, it holds for tens of seconds and empties as soon as your attention goes somewhere else. Hear a phone number, get interrupted before you write it down, and the number is gone.

What gets counted there is not digits or letters but chunks. 01012345678 is eleven characters and awkward to hold; broken into 010-1234-5678 it becomes three chunks and holds easily. The digits didn't change, only the load. How much sits inside one chunk barely affects the limit — the number of chunks is what sets it.

That is why the law pushes toward grouping rather than deletion. It doesn't say cut twelve menu items down to five; it says gather the related ones so the top level shows three or four. Gestalt principles — the tendency to perceive nearby and similar things as one unit — do the work here. Adjusting spacing and dividers alone can make the same twelve items read as three groups.

Seven is not a number to trust literally. Research after Miller puts the unaided limit closer to four chunks. What survives either way is the direction rather than the count: when a screen feels crowded, look for a way to group before looking for something to delete.

The limit bites wherever you decide how many things appear side by side at once. Top-level navigation, the rows on a settings screen, pricing cards, and the number of steps in a signup flow are all that decision. It also shows up in places that look like content rather than structure, such as how many filters a search page exposes before the rest go behind a toggle.

When a screen starts to feel crowded, work through three steps.

1. Count the chunks that are visible at the same time, not the total number of items. Twenty rows split across three tabs come to three chunks plus whatever sits inside the open tab.
2. Look for a basis to group by — same job, same object, same moment of use, in that order. If no basis appears, the problem is naming and categorization rather than quantity, and the place to go is the information architecture, the structure that decides how content gets divided, labeled, and connected.
3. Name each group. A group nobody can name won't fuse into one chunk in anyone's head either. If items keep landing in a bucket called "other," go back to step 2.

Progressive disclosure, revealing information in stages only when it's needed, handles the same limit from another side. Show only "copy link" on a sharing screen and hide permission settings behind "more options," and the feature count stays the same while the chunks anyone has to carry drop.

"There are eleven items in the top nav. Let's group the similar ones and get it down to four."

A proposal to add a layer above rather than delete anything.

"It isn't a rule that you can't go past seven. It's asking how many chunks are visible at once."

Correcting someone who is about to treat the number as a pass-fail threshold.

"Twenty settings rows, but split across three tabs it's under seven on any one screen."

Keeping the total the same while cutting how much is visible at a time.

At Pagedeck this came up when the sidebar was redesigned. Documents, templates, shared, trash, notifications, search, favorites and recents sat in one column of eight, and interviews kept turning up the same line: people found things, but only by scanning every time. Noa didn't propose deleting any of the eight. She brought a version that grouped them into workspace, my documents, and tools.

Theo asked how it helped when the item count was identical. Noa's answer was that the thing you scan went from eight to three. Grace pointed out that search, which everyone used constantly, now needed one extra click inside tools, and that item was pulled back out of the grouping. The law didn't decide anything; it said what to count.

The common mistake is reading this as a seven-item ceiling. There is exactly one number in it, which makes it look like a rule, and it's convenient to cite in a meeting. But the original observation is about the size of short-term memory, not about how many things belong on a screen. When items stay visible and can be re-read with your eyes, a fifteen-row list causes no trouble; when each step has to be remembered to make the next choice, five is already too many. Treat it as a ceiling and you get a twenty-item list chopped into three pages of seven, which is worse.

Believing that a smaller count is automatically easier comes from the same root. Fewer visible items make a screen look tidier, so it feels like progress. But if the items were moved down a level rather than removed, people scan less and dig more. Cut the top nav to four and push the rest two levels down, and something that used to be one glance away now takes three clicks. What to count is not the items on one screen but the total load between a person and where they're going.