UX Took the Wrong Half of Cognitive Load Theory
Most UX writing on cognitive load repeats the same basic formula: working memory is limited, extraneous processing is waste, so reduce cognitive load wherever you can. That advice is useful, but it is only half the theory. The missing half is that some effort is not waste at all. It is an investment in competence. Forget that, and you start removing exactly the stuff that helps people actually get good at the product. NN/g Sweller 1988 Paas & van Merriënboer 2020
A lot of UX practice took the "reduce load" half of cognitive load theory and kind of left the rest on the table: which kinds of effort help users build durable mental models, and which kinds just drain attention for no reason? So cognitive load became a reason to clean things up, but not really a reason to think much about expertise.
The useful distinction UX flattened
Cognitive Load Theory starts from a simple fact: working memory is limited, especially for novices dealing with unfamiliar material. In the classic framing, there are three categories: Sweller 1988
- Intrinsic load: the complexity inherent to the task itself.
- Extraneous load: difficulty created by poor presentation or interface design.
- Germane load: effort directed toward schema formation — building the mental structures that make future performance easier. Sweller 2010
That third category became controversial. Kalyuga argued that germane load may not be meaningfully separable from intrinsic load as its own category. But for design, the more useful modern framing comes from Paas and van Merriënboer: the goal is not simply to reduce load, but to substitute productive for unproductive cognitive load. Kalyuga 2011 Paas & van Merriënboer 2020
Working memory is a fixed budget. The dashed frame is the ceiling. What fills it is the design question.
That reframing is what UX needed. Some effort helps users build schemas. Some effort is just confusion. Good design should remove the second without automatically deleting the first. If you treat all effort like bad effort, you end up with users who can get through a flow but don't really know what they're doing.
A simple product example
A first-time Figma user opening a dense component library is facing real intrinsic complexity. Nested components, overrides, and variant states are conceptually hard whether the interface is polished or not. But a settings panel that buries a key option four levels deep adds extraneous load: the user is spending mental effort on navigation instead of the task.
The standard UX lesson is correct as far as it goes: remove extraneous load. Obviously. Nobody is asking for more confusing menus. The problem starts when that lesson expands into a blanket assumption that all effort is bad.
Where UX got selective
If you look at the most widely cited UX explainers on cognitive load, the pattern is clear. Nielsen Norman Group's "Minimize Cognitive Load to Maximize Usability" focuses on subtraction: reduce clutter, offload memory demands, rely on familiar mental models. Smashing Magazine's version is similar, with advice centered on removing steps, hiding options, and reducing visible complexity. NN/g Smashing Magazine
None of that is wrong. But it is incomplete. These sources treat mental effort mainly as something to be minimized, not something to direct. The missing question is whether a particular form of effort helps users build a more durable model of the system over time. At some point "don't make me think" started drifting toward "don't ask me to learn anything," and that's a different idea.
Learnability is named, but not explained
UX frameworks do talk about learnability. Nielsen's usability model includes it explicitly, and classic heuristics make room for accelerators that support expert users. But these frameworks mostly describe desired outcomes, not the mechanism that gets you there. Nielsen 1994
They can tell you that experts should be faster than novices. They are less helpful at explaining why inconsistent affordances across screens prevent users from building transferable schemas, or why progressive disclosure can either scaffold mastery or permanently conceal structure. Cognitive load theory, used properly, gives you that mechanism. Without that layer, "learnability" can start meaning "the onboarding didn't annoy me too much," which is a pretty low bar.
Why difficulty can be good design
This is where Bjork and Bjork's work on desirable difficulties becomes useful. Their research shows that conditions that make learning feel fast and easy in the moment often produce weaker long-term retention, while conditions that create certain kinds of challenge often improve retention and transfer. Bjork & Bjork 2011
Their key distinction is between retrieval strength and storage strength. Retrieval strength is how accessible knowledge feels right now. Storage strength is how deeply that knowledge is embedded and connected to other knowledge. A system can make users perform well in the moment without helping them build durable understanding. Bjork & Bjork 2011
That kind of design behaves like cramming for a test: performance looks great in the moment and then falls apart surprisingly fast. A product that hides complexity, explains every step, and scaffolds every decision may maximize immediate task completion while minimizing actual learning. Users succeed while the scaffold is present, but they may not build the schema needed to transfer that success to a new feature, an edge case, or a less guided version of the same flow.
Two ways to perform well today — only one of them survives the week.
The nuance here matters. Some challenge helps because it gives the user something real to internalize. Some challenge is just the interface being annoying. Bjork and Bjork's work is useful partly because it helps separate those two.
The tension UX has to manage
There is a real tension here. Carroll and Rosson's "paradox of the active user" showed that people do not usually approach software like students. They do not want manuals. They do not want long training flows. They want to start doing the task immediately. Carroll & Rosson 1987
That insight is correct. Interfaces should support immediate action. But it does not follow that products should remain permanently optimized for first-use immediacy. An interface can serve the active beginner while still helping repeated users build deeper competence over time. Your onboarding can't be the one and only time the product bothers teaching anything.
That is the real design tension: support action now without trapping people in perpetual shallowness later.
What failure looks like in practice
The expertise reversal effect gives this failure mode a name. Methods that help novices can become unhelpful or even harmful once users have developed partial schemas. Once someone already understands a pattern, repeated scaffolding becomes redundant processing. Kalyuga et al. 2003
The same scaffolding, tracked from first use to fluent use.
Google Docs is a good example. Tooltips, prompts, and suggestions are helpful when a user does not yet know where features live. For an experienced user who already knows shortcuts and formatting patterns, those same prompts can become interruptions. The scaffold that helps the novice becomes friction for the intermediate. If you've ever had autocomplete get weirdly confident while you were just trying to finish a sentence, you've already felt this.
This is one reason standard UX metrics can mislead. A heavily scaffolded experience can test extremely well with first-time users while quietly slowing down people who use the product every day. The dashboard still says things are great. Meanwhile the people who know the tool best are finding workarounds.
Hidden controls are a structural problem
Hidden controls make the same mistake in another form. Philip Kortum argues that gesture-only actions, long-press behaviors, and hidden navigation patterns remove the visible cues that let users understand what a system can do. Don Norman's distinction still matters here: visible controls put knowledge in the world, while hidden controls require knowledge in the head. Kortum 2025 Norman 2013
Consider iOS Reachability. It exists, but activating it depends on knowing a specific gesture at the bottom edge of the screen. Nothing in the interface teaches the feature. Users who were never shown it often never discover it. As far as the product is concerned, the feature exists. As far as plenty of users are concerned, it absolutely does not.
Nielsen Norman Group found that hamburger menus significantly reduce navigation use compared with visible navigation and increase task time. Short-term discoverability is only the surface problem; underneath, the interface never really teaches the structure of the tool. It's hard to learn a system's shape when half of it keeps disappearing. Pernice & Budiu, NN/g
What better design should optimize for
The target is a product that gets more legible and more powerful the longer people live in it, even if that means accepting a bit of effort up front.
That means designing products that:
- Reduce clutter, inconsistency, and wayfinding overhead.
- Keep important capabilities visible enough to support discovery.
- Use progressive disclosure as scaffolding, not permanent concealment.
- Offer shortcuts, command palettes, and macros that reward users who invest in learning the system.
- Let scaffolding recede as competence develops. Paas & van Merriënboer 2020 Kalyuga et al. 2003
Slack thread replies are a useful example. They solve a real organizational problem, but because they are often hidden behind hover behavior, many users never discover them. Short-term discoverability is only the surface problem; underneath, the interface never really teaches the structure of the tool. So Slack ends up being great for quick back-and-forth, but a lot worse at teaching people how not to make a mess.
Checklist for product teams
If the goal is productive rather than indiscriminate simplification, these are the questions worth asking:
UX successfully squeezed out a lot of extraneous load and, along the way, quietly squeezed out the effort that was building schemas too. The two got treated as the same thing.
The takeaway from cognitive load theory is pretty specific: be careful which difficulties you remove, because some of them are doing real work.