What You Make Them Carry: Cognitive Load

A payment form asks for the code from a text message. You leave the app to read it, come back — the field is empty, and so are the three above it. You start again. This time you memorise the code first, but by the time the form loads you're not sure whether it ended in 4 or 7.

Nobody designed this to be cruel. Each decision was locally sensible: clear the form for security, keep the code short, don't clutter the screen. Together they built a task that requires you to hold something in your head, and holding things in your head is the one thing people are worst at.

The workbench is not yours to fill

The How to Learn sphere covers the mechanism in detail: working memory is a tiny workbench, roughly four items at once, and everything you're currently juggling has to fit on it. That fact doesn't change when the person sits down in front of your product. What changes is who is putting things on the bench.

John Sweller's cognitive load theory splits the total into parts, and for a designer the split is unusually practical:

Intrinsic load — the difficulty of the actual task. Choosing a flight for a trip with three constraints is genuinely hard. This is the user's problem and it's legitimate; it is what they came for.

Extraneous load — everything the presentation adds on top. Where the button went, what that word means, which of these two panels is current, what you have to remember from the previous step. This is your contribution.

The job splits cleanly along that line: drive extraneous load to zero so the whole bench is free for the task the person actually has. An interface is not supposed to be interesting. It's supposed to leave room.

Every slot your interface occupies is a slot the task doesn't get.

Recognition beats recall

Of everything on this list, this is the highest-value rule, and it's rule number six in Jakob Nielsen's usability heuristics: minimise memory load by making objects, actions and options visible.

Recall — producing something from nothing — is slow, effortful and unreliable. Recognition — seeing something and knowing it — is nearly free. The design consequence is simple: whenever a person needs information, put it where they need it, not where it logically belongs.

Look for the pattern in your own products:

A confirmation screen that doesn't show the address they typed, so they have to go back to check.
A code that must be carried from another app into a field that clears on blur (paste it for them; better, read it and fill it).
A shortcut mentioned once in an onboarding tour and never again.
A filter that's applied but not visibly listed, so people forget it's on and think the data is wrong.
A settings panel where the labels only make sense if you remember what the previous screen called the same thing.

Every hidden menu is a bet that people will remember it exists. They mostly won't.

Hick's law, honestly stated

The popular version is "fewer options, faster decisions." The real finding — William Hick in 1952, Ray Hyman in 1953 — is narrower and more useful: decision time grows with the logarithm of the number of equally likely alternatives.

The logarithm matters. Going from 2 options to 4 costs about as much as going from 4 to 8, or 8 to 16. Options are not equally expensive; the first few are.

And "equally likely" matters even more. A menu of a hundred items is not a hundred-way decision if it's grouped into six labelled sections — it's one choice among six, then one among fifteen. That's dramatically cheaper than either the flat hundred or the popular "just cut it to seven" advice.

So the sequence is: group first, prioritise second, delete third. Deleting is where beginners start, and it's the move most likely to break something someone needed.

The most cited caution is Sheena Iyengar and Mark Lepper's jam study (2000): a tasting table with 24 jams attracted more passers-by than one with 6, but the small selection sold roughly ten times more. Later replications have been mixed, so don't wield it as a law — but the direction holds where choices are hard and comparison is expensive, which describes most pricing pages ever made.

Fitts's law, and where it bites

Paul Fitts, 1954: the time to hit a target grows with distance and shrinks with size. It sounds like an equation for mice; it is in fact the reason several everyday design rules exist.

Primary actions get to be big. Not for emphasis — for speed. The thing people do most often is the thing that should be easiest to hit.

Edges and corners are infinitely large. The pointer stops at the screen edge, so a target sitting flush against it is effectively unmissable — the reason menu bars and docks live where they live.

On phones, distance means thumbs. Reach is a physical arc, not a rectangle. The bottom of the screen is comfortable, the top corners are not, and this is why navigation migrated downward on mobile over the last decade.

Small targets are an accessibility failure, not a style. WCAG 2.2 sets a minimum target of 24×24 CSS pixels; Apple's guidance says 44 points, Google's says 48 dp. Below that you are not designing a compact interface, you are designing a miss.

Never put a destructive action next to a frequent one. Fitts's law guarantees occasional overshoot. "Delete" beside "Save" isn't a risk, it's a schedule.

Tesler's law: complexity doesn't vanish

Larry Tesler, who spent his career on this, formulated the principle of the conservation of complexity: every process has an irreducible amount of complexity, and the only question is who absorbs it — the user, the designer, or the engineer.

This reframes "simplify" from a slogan into a decision. A date can be typed in eleven formats. Someone has to handle that: either the user, by learning your format and being scolded when they get it wrong, or the code, by parsing all eleven. A phone number has spaces, dashes and country codes. An address has a postcode that could be derived. A file could be converted rather than rejected.

Every one of these is a small amount of engineering work traded against a small tax on every user, forever. The trade is almost always worth making, and it's almost always argued about as if it were a feature request rather than a design decision.

Disclose progressively, and set the defaults

Two mechanics let you serve complicated products without a complicated first screen.

Progressive disclosure — show the common path, keep the rest one deliberate step away. Not hidden: deferred, with a visible way in. The test of a good "Advanced" section is whether the person who needs it can predict that it's there.

Defaults — the most powerful and least discussed tool in the field. Almost nobody changes a default, which means whoever sets them designs the behaviour of the majority. Every default is a decision you're making on behalf of thousands of people who will never notice it was a decision. Set them for the common case, not for the safest-sounding one, and never set a default that costs a user money or privacy they didn't ask to spend.

In practice

Count the decisions on the screen. Go through and list every point where the person must choose or recall something. If the number is above five for a routine task, you have a load problem regardless of how clean it looks.

Show what they entered. On every confirmation, summary and error, display the values in question. This one habit removes a surprising share of back-and-forth navigation.

Delete one field. For any form, take the field you're least sure about and ask what would happen if you derived it, defaulted it, or asked later. Repeat until removing the next one would genuinely cost you.

Group before shortening. When a list is too long, don't cut it first — label it into sections and see whether the problem disappears. Usually it does.

Measure your primary target. Is it big, is it near the thumb, is it a safe distance from anything destructive? Three questions, thirty seconds.

Move complexity into the code. Every time you're about to write a format hint — "DD/MM/YYYY", "no spaces please" — ask whether the parser could just accept it instead. That hint is a tax notice.

Check yourself

Close the article and answer in your own words:

What's the difference between intrinsic and extraneous load, and which one is yours to remove?
Why is "recognition over recall" the highest-value rule on the list?
What does the logarithm in Hick's law change about the advice "fewer options"?
Why does grouping beat deleting, and what order should you work in?
Name three practical consequences of Fitts's law you could apply to a screen today.
Under Tesler's law, who absorbs the complexity of eleven date formats, and how do you decide?
Why are defaults a design decision rather than a technical detail?

In short

Working memory holds about four items. Every one your interface occupies is one the user's real task doesn't get.
Intrinsic load is the task; extraneous load is what your presentation adds. Your job is to drive the second to zero.
Recognition beats recall: put information where it's needed, not where it belongs. Hidden menus are a bet people will remember.
Hick's law is logarithmic and assumes equally likely options. Group first, prioritise second, delete last.
Fitts's law: big primary targets, edges are free, thumbs reach the bottom, minimum 24–48 px, never put delete beside save.
Tesler's law: complexity is conserved. The only question is whether the user or the code absorbs it — usually the code should.
Progressive disclosure defers rather than hides. Defaults design the behaviour of the majority, so set them deliberately.