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:

  1. Estimate how much information you're asking a user to hold at each step of a flow.
  2. Reorganize complex information into units the brain handles better (chunking).
  3. 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. 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.

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)

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 (15 minutes)

Pick a multi-step flow you use (a purchase, a long form, an administrative process).

  1. Screen by screen, note what you have to remember from earlier steps in order to continue.
  2. Mark a point where the system forces you to remember instead of simply showing you the data.
  3. Look for a list of more than seven or eight items with no grouping.

Suggested solution: the most common case is a code, a total or a personal detail that appeared earlier and that the current screen assumes you remember. If you also found the long ungrouped list, there's your second finding. Neither one is the user's fault: they're the small table asking for help.

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.

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