Cognitive Load in UX: How to Spot It and Reduce It

Your working memory holds about four things at once. The average online checkout asks you to deal with 11.3.

That gap is the whole problem. Nelson Cowan's 2001 paper in Behavioral and Brain Sciences, titled "The Magical Number 4 in Short-Term Memory," put the realistic limit at roughly four chunks for most adults under most conditions, revising the famous "seven plus or minus two" that George Miller floated back in 1956. Meanwhile Baymard Institute found the average e-commerce checkout in 2024 still displayed 11.3 form fields, when most sites need only 8 (figures refreshed in Baymard's March 2026 dataset). We keep building interfaces for a mind that can hold a lot, and shipping them to the mind we actually have.

Here is the part most "simplify your UI" advice gets wrong, though. Cognitive load is not the enemy. Jakob Nielsen made this point sharply in an August 2026 piece arguing that load is a budget, not a villain. Thinking hard about a genuinely hard decision is fine. The failure is spending a person's limited mental budget on things that have nothing to do with their goal, like remembering a code from the previous screen, or decoding which of nine buttons does the thing they came to do.

The short version: Cognitive load is the total mental effort it takes to use an interface. Working memory can only hold about four chunks of information at once, so when a design forces people to remember, decode, or compare more than that, they slow down, make errors, and leave. You reduce it by cutting choices, chunking information, showing one thing at a time, and never making users hold in their head what the screen could just show them.

What is cognitive load in UX?

Cognitive load is the amount of mental effort a person spends to understand and use your interface. It comes in three flavors, and only one of them is worth protecting.

The distinction matters because it tells you what to cut and what to leave alone. Load you add by being sloppy is the first thing to go. Load that comes from the task itself is not yours to remove, it is yours to support.

Most of what feels "heavy" in a bad interface is extraneous. It is not the decision that is tiring, it is everything piled on top of the decision.

How many things can working memory actually hold?

About four. That is the number worth designing around.

Miller's 1956 "seven plus or minus two" is the one everyone quotes, and it is a real part of the history, but Cowan's 2001 reanalysis landed on roughly four chunks as the honest working figure once you stop people from silently rehearsing. And that memory is fragile. In the classic Peterson and Peterson experiment from 1959, when people were blocked from rehearsing a three-letter string, their recall fell from about 80% after three seconds to roughly 10% after eighteen. Eighteen seconds. That is shorter than the time it takes to find your card, read a code off one screen, and type it into the next.

So any time your design asks someone to carry a value from one place to another in their head, you are betting against a clock that runs out in under twenty seconds. You will lose that bet more often than you think.

What makes an interface feel heavy (the signals)

Cognitive load rarely shows up as one obvious disaster. It shows up as a hundred small taxes. A few patterns I look for first:

Memory tax. The screen makes you remember something it could have shown you. A confirmation code on one page and the input on the next, with no way to see both. An error that scrolls away before you can read it. A filter state you can't actually see while you browse.

Decision tax. Too many equally-weighted choices at the same moment. This is Hick's Law, which says decision time grows with the logarithm of the number of options. Eleven menu items with no hierarchy is not eleven times slower than one, but it is slower, and worse, it makes people feel slow, which is its own cost.

Translation tax. The interface speaks its own language and makes you translate. Internal status codes, unlabeled icons, "Entity type 3," units you have to convert in your head. Every translation is working memory spent on plumbing instead of the goal.

Visual tax. No hierarchy, so the eye has to do the sorting the designer skipped. When everything is bold, nothing is, and the brain pays to figure out where to look. This is the same principle behind behavioral design: the smallest structural choices quietly shape what people can and can't do.

I felt all four of these at once building the MOVI payments app for small businesses in Venezuela. When prices change through the day under hyperinflation, a merchant cannot afford to hold a number in their head across three taps. The whole design job was removing the memory tax, because the context already supplied all the intrinsic load anyone could handle.

How do you reduce cognitive load in UX?

You reduce cognitive load by cutting choices, chunking information, deferring complexity, and refusing to make people remember anything the screen can show. Here is the order I work in.

Cut the options before you arrange them. The fastest load reduction is removing a choice, not styling it better. Baymard's 11.3-to-8 gap on checkout fields is a reminder that the best field is often no field. Ask of every element: does the user need this now, or am I protecting an edge case at everyone's expense?

Chunk, don't list. A sixteen-digit card number is brutal as one string and easy as four groups of four. Same information, a fraction of the effort. Group related inputs, break long forms into labeled steps, and let people hold one small set at a time instead of one big blur.

Show, don't make them remember. Keep the code and the input on the same screen. Keep the running total visible. Persist the filter state in view. If a value matters on the next step, carry it forward for them. This single rule kills most memory tax on its own.

Defer the complexity. Progressive disclosure means the advanced stuff waits behind a clear door until someone asks for it. The default view answers the common case; the power user is one tap from the rest. You are not hiding features, you are refusing to charge everyone for the few who need them.

Lean on recognition over recall. People are far better at recognizing an option in a list than conjuring it from memory. Autocomplete, sensible defaults, recently-used items, and clear labels all move work off the user's memory and onto the machine, which has plenty to spare. The right word at the right moment does a lot of this quietly, which is why microcopy is one of the highest-leverage nudges you have.

Give hierarchy to the eye. One clear primary action per screen. Real type scale. Grouping and spacing that pre-sort the page so the user doesn't have to. Visual hierarchy is cognitive load reduction you can see.

None of this is about dumbing anything down. It is about spending the user's four chunks on their decision, not on your plumbing. The same instinct runs through the broader psychology principles behind good UX: design with the mind people actually have.

How do you measure cognitive load?

You can't see it directly, but you can read its shadows. Watch for rereading, hesitation, back-and-forth scrolling, and the small "wait, what?" pause in a usability test. Track task completion time and error rates on the flows you change; honest simplification shows up as both going down. For a quick structured read, a short NASA-TLX questionnaire after a task gives you a self-reported load score you can compare before and after. The numbers are rough, but the direction is usually obvious once you look.

Key takeaways

• Working memory holds about four chunks, not seven; design for four and you'll rarely overshoot.

• Cognitive load is not the enemy. Wasted load is. Protect the effort that belongs to the task, cut the effort your design added.

• The average checkout still shows 11.3 fields when 8 would do. The best field is often no field.

• Never make people remember what the screen can show them. Memory decays in under twenty seconds.

• Chunk information, defer complexity, favor recognition over recall, and give the eye a hierarchy to follow.

FAQ