Module 2: Cognitive load and memory

Designing for a brain with limits

Learning objectives: By the end of this module, you will be able to:

Estimate how much information you're asking a user to hold at each step of a flow.
Reorganize complex information into units the brain handles better (chunking).
Question inherited numeric rules, starting with the "magical seven", instead of applying them from memory.

Estimated time: 1-1.5 hours

If you've worked in UX or design for a while, you've surely heard some version of this rule: "menus shouldn't have more than seven options, because human memory handles seven things at a time". It's one of the most repeated lines in the field. It's also one of the worst understood.

Working memory, the one you use to hold information while you do something with it, is real and it's limited. But the magical number, where it came from and what the person who proposed it actually said, is a different story from the one going around. Miller's paper is called, literally, The magical number seven, plus or minus two, and that "plus or minus two" already says a lot about how far it got stretched afterwards. This module is about that: the real limits of attention and memory, and a couple of myths we drag along as if they were law.

Everything in this module is cognitive at the root: how the brain holds, groups and discards information while it operates.

2.1. The small work table analogy

Think of working memory as a small table. Not a wide desk: a table that fits three or four objects in view, no more. Everything you need for the task at hand lives up there, available instantly. The rest is stored in a huge warehouse at the back (long-term memory): it fits almost infinitely, but bringing something out of there takes time and effort.

When you design a screen that forces the user to remember a piece of data from three steps back, you're asking them to keep that object on the table while doing other things on top of it. The table saturates, something falls off, and the person makes a mistake or gives up. Not because they're distracted: because the table is small for everyone.

The trick that does work isn't making the table bigger (you can't), it's stacking better: joining several loose objects into one. That's called chunking, and it's the most useful thing in this module.

2.2. How to lower the memory load of a flow

Step 1: count what the user has to hold

On each screen, list what information from previous screens they need to remember in order to continue. If it's more than two or three things, you have a problem.

Step 2: don't make them remember, show it

Any data the user entered earlier and needs now, put it in plain view: a summary, a prefilled field. Recognizing is cheaper than recalling, and it's literally one of Nielsen's ten heuristics (recognition rather than recall).

Its limit: showing everything also saturates. Show what's relevant to the current decision, not the full history.

Step 3: group (chunking)

Take long, flat lists and organize them into meaningful categories. A card number reads better in blocks of four than as sixteen digits in a row.

Its limit: the chunk has to match what the user already knows. Grouping "by type of procedure" works if the person thinks in procedures; if not, your category is noise. A chunk for an expert can be a hieroglyph for a novice.

Step 4: fewer options, but for the right reason (Hick's law)

Hick's law says that the more simple, evenly matched alternatives there are, the longer the person takes to choose; reducing them speeds up the decision.

Its limit: Hick's law assumes simple, equally probable options. In a real interface there are categories, hierarchy and familiarity that break that math. "Less is always better" is a bad reading: sometimes the person wants to see everything (a restaurant menu, a catalog). Cutting for the sake of cutting frustrates as much as overwhelming.

2.3. Case study: "MediTurno" (health scheduling)

MediTurno let people book medical appointments, and it was losing users along the way for no obvious reason. The team reviewed the flow through the lens of memory:

Working memory: at step 5, the screen asked for a plan code that had appeared at step 2, without showing it again. The table no longer had it. People went back, got lost, gave up.
Chunking: the selector showed 18 specialties in a flat alphabetical list. Nobody reads 18 items without grouping; you scan them blind.
Hick's law: when picking a time, 40 identical blocks appeared with no split between morning and afternoon. Every choice cost more than it needed to.

The fixes were straightforward: carry the code forward (show it, don't ask for it from memory), group the 18 specialties into five areas, and split the times by part of day.

The methodological point is another one: the team didn't ask "did that feel easy?". It measured error rate and time on task, and that's where the exact moment the table collapsed showed up. Perceived ease and actual performance don't always match: the aesthetic-usability effect from Module 1, again.

2.4. Application activity (20 minutes)

Open an app or a site you use often and pick a multi-step flow: buying a ticket, signing up for a service, setting up a new account. Walk through it paying attention to one thing only: what the system is demanding of your head.

Step 1: audit the working table

Walk through the first three screens and note every piece of data the system forces you to hold in memory in order to decide on the next one.

If at any point you have to go back to check something, or if the count goes past three or four items at once, mark that screen: there's a violation of "recognition rather than recall" right there. Watch the threshold, because it's the whole point of this module: it's three or four, not seven.

Step 2: hunt the magical seven myth

In that same app, look for a menu, a settings panel or a long form.

Check whether there's a flat list of seven to nine items with no visual structure, or whether the information is grouped in a way that serves the system rather than you. That's the trail the old rule leaves behind: someone assumed the user can hold seven things and didn't bother to group.

Step 3: propose the relief

Take one of the two problems and make a quick sketch, on paper, of how you would fix it.

If you picked the memory one, draw where you would put the summary or the prefilled field that saves the user from having to remember. If you picked the long list, apply chunking: reorganise it into blocks of three or four items, under categories that make sense for what the user already knows (not for how the database is organised). There's a third route this module didn't get to cover, progressive disclosure: show the essentials first and leave the rest behind a click, for whoever needs it.

Suggested solution: in step 1 the most common discovery is that the screen assumes you remember a discount code, an earlier total, or the filters you applied two clicks back. In step 2, a menu or a form that wears your eyes out because nobody grouped it.

But what matters isn't the finding, it's the sketch. If you managed to move the work from the user's memory to the interface's memory (showing the data instead of asking for it), or to break the list into meaningful blocks, you performed the whole operation: taking load off a table that cannot be made bigger. And if the sketch cost you considerably more than finding the problem did, that's the normal experience: spotting the friction is easy, designing the relief is the craft.

2.5. References

Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63(2), 81–97.
Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87–114.
Hick, W. E. (1952). On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4(1), 11–26.
Nielsen, J. (1994). 10 usability heuristics for user interface design. Nielsen Norman Group. nngroup.com

Additional material. From MIT's Introduction to Psychology (9.00SC): Memory I and Memory II.