Cognitive load is the real SaaS design problem
Three kinds of load, and teams keep cutting the wrong one
Thesis
Working memory holds about four items. Your settings page has forty toggles.
That comparison gets used to justify a lot of bad design work, and the reason it produces bad work is that it treats load as one quantity. It is not one quantity. Cognitive load theory has separated it into distinct types since the 1980s, and the distinction is the entire practical content of the field.
Extraneous load comes from how the interface is built: inconsistent patterns, ambiguous labels, hidden state, information you need in two places at once. It contributes nothing. Cut all of it.
Intrinsic load is the actual complexity of the task. Payroll is complicated because payroll is complicated. You cannot remove this. You can only move it, and moving it means somebody else carries it.
Germane load is the effort of building a mental model of the system. It is an investment, and a product that eliminates it produces a user who can operate the interface and does not understand the product.
The failure I see most often is not overload. It is a redesign that stripped germane load to look clean, left the extraneous load untouched, and shipped a product that is simpler on the first screen and impossible on the fourth.
Context
"Simplify" has been the dominant design instruction for fifteen years, and it produced real gains against genuinely terrible enterprise software. It also produced a generation of products where the primary action is hidden behind a hover, the system's state is not displayed anywhere, and the object model is deliberately obscured because exposing it would look technical.
Those products test well in a first-use study and lose users in month three, which is the hardest failure to attribute. Nobody churns and writes "your information architecture was hidden from me". They say it did not fit their workflow.
The other thing worth naming: load is not only per session. Between sessions, the user forgets. A weekly product has to be re-learned every week, and the cost of re-entry is where most business software actually loses people. Almost no design process measures it, because usability testing observes first use and then stops.
Research
Sweller, 1988, and the cognitive load theory that followed. Sweller's original work concerned problem solving and instructional design, and it established that working memory limits are the binding constraint on learning. Sweller, van Merriënboer and Paas developed the three-part taxonomy above.
One honest caveat, because it matters for how confidently the taxonomy should be used: the status of germane load has been revised. In the 2019 update, Sweller and colleagues treat germane load not as a separate additive source but as working memory resources directed toward handling intrinsic load. Anyone citing three independent quantities is citing a version the authors have since refined. The practical distinction between load that helps and load that does not survives the revision.
Miller, 1956, and why you should stop citing it. "The Magical Number Seven" is about channel capacity in absolute judgement and immediate memory span. It is not a finding about how many items belong in a navigation menu, and Miller was explicit that the recurrence of the number was something he found suspicious rather than foundational.
Cowan, 2001, is the citation you actually want. Reviewing the evidence, Cowan puts the working memory limit closer to four chunks rather than seven. Chunks, not items, which is the important part: a practised user holds a whole workflow as one chunk, and a novice holds each step separately. Load is relative to expertise, always.
Hick, 1952, and Hyman, 1953, established that choice reaction time grows logarithmically with the number of alternatives. This is real and it is routinely misapplied. It holds for simple choice reactions with prepared responses. Scanning a menu is dominated by visual search rather than by decision time, which is why splitting a fifteen-item menu into three fives can be slower overall despite reducing the choice count per screen. Use Hick's law where responses are prepared. Do not use it to justify menu surgery.
Fitts, 1954, on movement time as a function of distance and target size. The reason this belongs in a load discussion is that physical interaction cost and cognitive cost trade against each other: a hidden control has low visual load and high recall load, and the exchange is frequently a bad one.
Iyengar and Lepper, 2000, the jam study, and then the correction that should always accompany it. Twenty-four varieties attracted more attention than six and produced far fewer purchases, which became the canonical choice-overload result.
Scheibehenne, Greifeneder and Todd published a meta-analysis in 2010 across roughly fifty published experiments and found the mean effect of assortment size on satisfaction and choice to be close to zero, with large variation by condition. The effect is not robust in the way the folklore assumes.
That is not a reason to ignore it. It is a reason to be precise about the mechanism, and the mechanism that survives is comparability rather than count. Options are costly when they are hard to distinguish, and cheap when the difference between them is obvious. Which means the fix is usually clearer differentiation, not fewer choices.
Kalyuga and colleagues on the expertise reversal effect. Instructional support that helps novices measurably harms experts, because the scaffolding itself becomes redundant material that has to be processed. This is one of the most useful findings in the whole literature for product work: the optimal load for a daily professional tool is higher than the optimal load for an occasional consumer one, and a single design cannot be right for both.
Tesler's law of the conservation of complexity. Larry Tesler's observation, from practice rather than research, that complexity in a system is conserved: it can be moved between the user and the software, but it cannot be removed. Someone bears it. This is the sharpest available test of a simplification claim, and it is a question you can ask in a review: if this is simpler, who is now carrying the part that disappeared.
Argument
Audit for extraneous load specifically, because it is the only kind you should be cutting.
The inventory is concrete and most of it has nothing to do with feature count.
Inconsistent patterns. The same action behaving differently in two places forces the user to hold two rules where one would do. This is the largest single source of extraneous load in most products and it is invisible to anyone who works on the product daily.
Hidden system state. If the user cannot see what mode they are in, what is selected, or whether their last change saved, they have to remember it. Norman's gulf of evaluation names this: the effort of working out what the system has done.
Ambiguous labels. A label that requires a guess costs a decision every time it is read, and it costs it forever.
Split attention. Information needed together, placed apart. Reference material on one screen and the form on another. This one is well-tested in the instructional literature and transfers cleanly.
Decisions requested out of context. Asking for a setting before the user knows what it affects converts a simple choice into a research task.
Note what is not on the list: quantity of features, density of the interface, number of menu items. Those are sometimes correlated with load and they are not the same thing.
Intrinsic load can only be redistributed, so decide deliberately where it goes.
Tesler's question is the useful one. When someone says a design is simpler, ask where the complexity went.
Good redistributions: onto sensible defaults, so the user only engages the complexity when they need to deviate. Onto structure, where a clear object model makes the complexity navigable rather than absent. Onto the machine, where computation replaces a judgement.
Bad redistributions, all common: onto the user's memory, by removing a visible control and requiring them to remember a command. Onto support, by shipping something confusing and answering tickets. Onto a later moment, by hiding a decision until the consequences are expensive.
The bad ones all look like simplification on the screen where the complexity used to be. That is what makes them attractive.
Germane load is an asset and it is being destroyed on purpose.
A user who has built an accurate mental model of your product can predict it, recover from errors, and use features you never showed them. Getting there costs effort, and that effort is the germane category.
Products that eliminate it, usually by hiding the object model behind task-shaped wizards, produce users who can complete the flows you designed and nothing else. They cannot compose, they cannot recover, and they cannot grow into the product. Every question they have becomes a support ticket, because they have no model to reason from.
The design that respects germane load does the opposite: it exposes the object model plainly, uses one consistent metaphor, and makes the structure of the system visible in the navigation. That is more to take in on day one and dramatically less to carry on day thirty.
Progressive disclosure is right and it is usually implemented backwards.
Correct: a working default with depth available on request. The novice never sees the advanced surface and the expert reaches it in one action, and crucially the user can tell that there is more.
Incorrect: the primary action hidden behind a hover, a menu or a second click, so the interface looks calm and the main job is harder. This is not progressive disclosure, it is concealment, and Fitts's law prices it: you have traded visual quiet for recall cost plus movement cost, on the most frequent action in the product.
The test is frequency. Disclose progressively what is used rarely. Never disclose progressively what is used constantly.
Design for the session you are not measuring.
Re-entry load is the number that predicts retention in low-frequency products, and almost nobody measures it. The user returns after two weeks having forgotten their configuration, what they were doing, and what the third tab was for.
What reduces it: state that survives, so the product opens where they left it. A visible history of what they did last time. Names chosen from the user's vocabulary rather than yours, because familiar words are recalled and invented ones are not. And an object model consistent enough that a partial memory of it still works.
Set the load target per audience, because expertise reversal is real.
A tool used eight hours a day should be dense. Keyboard-driven, information-rich, minimal hand-holding, because the scaffolding that helps a first-time user actively costs an expert every day for years.
A tool used monthly should be guided, explicit and slower. If both audiences exist in one product, the resolution is a progression rather than a compromise: begin guided, and let the guidance retire as usage accumulates. The compromise design, which is what most products ship, is annoying for the expert and insufficient for the novice.
Examples
A settings page with forty toggles. The count is not the problem. The problems are that the toggles are not grouped by the thing they affect, half the labels require a guess, and none of them show their current effect. Grouped into six named sections with plain labels and visible consequences, forty is fine. Ungrouped, ten is too many.
An onboarding wizard that hides the object model. Five friendly steps, at the end of which the user has a working setup and no idea what a workspace is or how it relates to a project. Every subsequent question they have is unanswerable from their own model, because they were never given one. Germane load deferred is germane load doubled.
A weekly reporting tool. All the load is at re-entry. The right design opens on what happened since last time, names the last thing the user did, and requires no reconstruction. The wrong design opens on a fresh empty state every week and makes the user rebuild their context, which is a full re-learning cost seven days after the last one.
A barista-facing order screen. The relevant load is not the interface's, it is the interruption's. Someone making three drinks while holding a queue in their head cannot afford to reconstruct their place after glancing at a screen. So the screen has to be readable in a fraction of a second from two metres away, and it must never require a decision. This is the case where density is safety and every extraneous element is a real cost.
Counterargument
"Cognitive load is the excuse feature-poor products use. Every serious professional tool is dense, and users become expert in the ones that repay the effort."
The strong version is well supported by what people actually pay for. Excel, Figma, Blender, a Bloomberg terminal, a professional audio workstation: all are dense, all have steep learning curves, all are beloved by the people who use them daily, and all would be destroyed by a redesign optimised for first-use comprehension. The expertise reversal effect predicts exactly this, which means the research cuts against the standard interpretation of the research.
There is a second and sharper objection about the transfer itself. Cognitive load theory was developed for instructional design, where the goal is learning and the material is studied. A software tool is used, not studied, and its user is trying to accomplish something rather than to acquire a schema. Borrowing the taxonomy across that boundary is an analogy, and calling it evidence overstates it.
Where this is right. The density point is correct and I would go further: the instinct to reduce is frequently the least skilled available design move, because it requires no understanding of the domain. Anyone can remove things. And the transfer objection is fair. I am applying a learning framework to a tool context, the mapping is not exact, and it should be held as a useful lens rather than a result.
Where I think it is wrong. The objection conflates density with extraneous load, and the professional tools it cites are the best evidence against its own case. Excel is dense and rigorously consistent. Its object model is exposed, not hidden. A formula behaves the same way everywhere. Those tools carry high intrinsic load and near-zero extraneous load, which is exactly the argument I am making rather than a counterexample to it.
And on the transfer: the specific mechanisms with the best evidence, split attention and redundancy, are about the spatial and temporal arrangement of information, which is precisely what interface design controls. Those are the parts I would rely on. The three-way taxonomy I would use as a lens, and I would not pretend it is measured in this domain.
Practical implications
Ask Tesler's question in every review. If this is simpler, who is carrying the part that disappeared.
Audit extraneous load as a specific list. Inconsistent patterns, invisible state, ambiguous labels, split attention, out-of-context decisions. Fix those before touching feature count.
Stop citing Miller. Use Cowan's four chunks, and remember that a chunk depends on the user's expertise, not on your grouping.
Do not split menus on Hick's law. Visual search usually dominates, and splitting adds a navigation step.
Fix comparability before reducing options. The robust part of the choice-overload finding is about difficulty distinguishing, not about count.
Expose the object model. One metaphor, consistently applied, visible in the navigation. This is the germane load you want users to carry.
Disclose by frequency. Rare things behind a click, frequent things never.
Measure re-entry, not just first use. Bring someone back after two weeks and watch what they have to reconstruct.
Choose your load target by usage frequency, and prefer a progression over a compromise when you have both audiences.
Use the user's vocabulary. Recognition is cheap and recall is not, and a word they already know is free.
My perspective
Opinion, from my own design work.
The largest load reduction I have achieved came from deleting a concept, not a control. Designing a smart-home interface for people over fifty, the observation that changed everything was that nobody thinks in devices. They think in rooms and in things they do. Reorganising the product around rooms and routines removed no functionality and made the whole thing comprehensible, because it replaced a model borrowed from the hardware with one the user already had.
That is the pattern I would generalise. Load reduction by removing controls is usually a small win with a hidden cost. Load reduction by replacing your object model with the user's is a large win with no cost, and it is much harder to find because it requires watching people rather than auditing screens.
The second thing that work taught me is about states rather than structure. Every home automation interface I benchmarked had two states, on and off, and the state that actually occurs is unknown, because a device did not respond. An interface that cannot display uncertainty will assert something false, and the user's model breaks in a way they cannot repair. Designing the unknown state is load-bearing work and it is nearly always skipped.
What I have to be honest about: I have never measured any of this. No task times, no error rates, no re-entry study, in any project in my record. Everything above is reasoning from literature plus qualitative observation, and the observation was real but the numbers do not exist. That is the same gap I have in every other discipline I work in, and it is the one I would close first if I were starting again.
Conclusion
Cognitive load is three things and only one of them should be reduced. Extraneous load, which comes from inconsistency, hidden state and ambiguous language, should be attacked without limit. Intrinsic load cannot be removed, only moved, and moving it onto the user's memory or onto your support queue is not simplification. Germane load is the user building a model of your product, and destroying it to look clean produces a product nobody can grow into.
Density is not the enemy. Confusion is. The best professional tools carry enormous intrinsic complexity and almost no extraneous load, and that combination is available to any product willing to be consistent and to expose what it actually is.
Sources
- J. Sweller, "Cognitive Load During Problem Solving: Effects on Learning", Cognitive Science 12(2), 1988, 257–285.
- J. Sweller, J. J. G. van Merriënboer and F. Paas, "Cognitive Architecture and Instructional Design", Educational Psychology Review 10, 1998, and the 2019 update revising the status of germane load, Educational Psychology Review 31, 261–292.
- G. A. Miller, "The Magical Number Seven, Plus or Minus Two", Psychological Review 63(2), 1956: cited here as commonly misapplied.
- N. Cowan, "The magical number 4 in short-term memory: A reconsideration of mental storage capacity", Behavioral and Brain Sciences 24(1), 2001, 87–114.
- W. E. Hick, "On the rate of gain of information", Quarterly Journal of Experimental Psychology 4(1), 1952; R. Hyman, "Stimulus information as a determinant of reaction time", Journal of Experimental Psychology 45(3), 1953.
- P. M. Fitts, "The information capacity of the human motor system in controlling the amplitude of movement", Journal of Experimental Psychology 47(6), 1954.
- S. S. Iyengar and M. R. Lepper, "When Choice is Demotivating", Journal of Personality and Social Psychology 79(6), 2000, 995–1006.
- B. Scheibehenne, R. Greifeneder and P. M. Todd, "Can There Ever Be Too Many Options? A Meta-Analytic Review of Choice Overload", Journal of Consumer Research 37(3), 2010, 409–425.
- S. Kalyuga, P. Ayres, P. Chandler and J. Sweller, "The Expertise Reversal Effect", Educational Psychologist 38(1), 2003, 23–31.
- D. A. Norman, The Design of Everyday Things, revised edition, Basic Books, 2013: the gulf of evaluation.
- L. Tesler, the law of conservation of complexity. Practitioner observation, not research.
Related reading in this archive
- Hublix: the rooms and routines decision, and the unknown state
- Cafe ordering: the barista-facing screen described above
- Designing products when AI is part of the interface
- Designing under uncertainty
- Design systems under non-deterministic output: the state enumeration that follows from the load argument above