Reduce short-term memory load

What it is

Reducing short-term memory load means necessary objects, options, summaries, and rules appear at the decision point rather than requiring users to remember IDs, prices, filters, commands, or steps across screens and time. This golden rule covers more ground than "users should not have to remember information across screens": that card is specifically about screen transitions, while this one covers any moment that requires holding several pieces of information in mind at once to make a judgment, even with no page change at all — for instance, adjusting one filter in a panel while having to remember the current value of three other conditions that are not shown in the current view.

Why it happens

The number of independent items working memory can hold at once is far smaller than the folk "seven plus or minus two"; more rigorous estimates put the real figure closer to four chunks, and reliability drops noticeably past that. Separate from capacity is an independent decay mechanism — without active rehearsal, content fades naturally within roughly ten to twenty seconds under distraction-free conditions, and screen changes, waiting, and interruption all accelerate that decay. These two mechanisms operate independently: fixing "how many items are visible at once" does nothing to slow decay over time, and fixing "how long the user can stay on the screen" does nothing to expand how many items can be handled at once. An interface that optimizes only one of the two will still fail users on the other, which is why reducing memory load has to be checked against both count and duration rather than treated as done once the more visible of the two problems is fixed.

Where it stops holding

One widely repeated but imprecise claim needs correcting here: treating "seven plus or minus two" as a general capacity ceiling for design purposes (such as "menus are fine as long as they have seven or fewer items") comes from Miller's early estimate; more rigorous replication work puts real capacity closer to four chunks, so using seven as a design redline already exceeds what most people can reliably hold, and it should not be cited as scientific justification on its own. A second boundary: reducing memory load does not mean compressing displayed information without limit — folding necessary parameters into several layers of menus does mean the user no longer has to remember them, but seeing them again now costs extra clicks, which trades memory cost for operational cost, and folding too deep can end up slower overall. Expert users form a special case: someone who repeatedly handles the same class of task has already chunked the interface's scattered information into their own mental structure and can infer what is not shown from a compact layout — forcing a full summary onto the screen for them is unnecessary visual noise. It is infrequent tasks and new users who depend most on having the full external cues laid out.

Applying it

• Walk through every decision point in a core task and list the information items the user must hold at once to make that decision — ID, price, condition, permission, a previous choice — anything exceeding four items and not currently in view is a candidate to fix.
• For forms and panels with cross-step dependencies, keep a selected-item summary on the current screen ("X selected, current condition Y, step n of m") instead of requiring the user to recall what was entered earlier.
• For comparison tasks, provide a side-by-side view or a pinnable summary bar to cut down on switching views back and forth to check values.
• How to check: count the number of independent information items each key step requires the user to hold simultaneously, and flag any step exceeding four as a high-risk point; then test leave-and-return, recovery after interruption, and screen-reader paths, logging which content can only be completed with the user's own screenshots or notes — those are the genuine sources of memory load in the current design.

Related

• Same group: B3.11.1 Strive for consistency · B3.11.2 Provide universal usability · B3.11.3 Offer informative feedback · B3.11.4 Design dialogs to yield closure · B3.11.5 Prevent errors · B3.11.6 Permit easy reversal of actions · B3.11.7 Keep users in control
• Nearby: A6.02 Working Memory Capacity · B3.06 Recognition over Recall
• Search terms: short-term memory · cognitive load · chunking · context preservation