Mechanism
Cognitive load theory might actually be doing less work than we think
I was sitting in on a product critique last week where someone killed a design because it was "too much cognitive load." When pressed on what that meant concretely—what task would fail, for whom, under what conditions—the room went quiet. We'd borrowed a term and used it as an explanation, which is the opposite of how frameworks are supposed to function.
The honest answer is that cognitive load does describe something real. The Swede Chandler's work in the 1980s mapped out genuine constraints on working memory, and you can measure them. But here's where it gets slippery: the framework predicts *effort*, not *outcomes*. You can make something cognitively taxing and watch people still accomplish the goal. Sometimes struggle is productive. Sometimes the "simplification" you impose creates a different kind of friction downstream. I think about how Apple's obsessive minimalism occasionally forces users into more steps than a slightly messier interface would require, yet people generally don't hate it. Why? Because the cognitive load framework doesn't account for narrative coherence, or status, or the satisfaction of operating something austere.
The real problem is that "cognitive load" has become a catch-all for "I have an intuitive sense this feels cluttered." It's not wrong to feel that way, but the framework doesn't actually tell you whether that intuition will map onto actual performance, learning, error rates, or user satisfaction. It's a useful diagnostic *hint*—go measure the thing you suspect is true—not an explanation. The moment someone says "this is cognitively overloaded," I want to ask: compared to what, for which user, doing which task, with what alternatives available?
2 comments
Log in to comment.
I spent three years watching teachers redesign lesson materials based on cognitive load theory, and you've nailed what bothered me about it. The classroom is where this breaks down most visibly.
A teacher would strip a geometry problem down to minimal steps because "working memory can only hold 7 things." Fine. But then students who needed to see the *messier* version—the one that showed dead ends, the one that let them build intuition by wrestling with complexity—they'd actually learn less. The simplified version felt cognitively lighter but taught almost nothing durable. Meanwhile, a student tackling the ungainly version with scaffolding would get stuck, struggle, then *retain it*. The framework predicted the wrong outcome because it only measured momentary cognitive demand, not learning.
What I kept seeing is that teachers used it to justify designs they already preferred for other reasons (clarity, aesthetic preference, control), then pointed to the theory when questioned. It gave intuition a permit. The honest ones would admit: "I think this works better because students aren't distracted by noise"—which is about attention and context, not working memory capacity. That's a different conversation.
The question you should ask in design too: are you actually measuring what the framework claims to predict? Because I'd bet most of the time people aren't. They're measuring ease-of-use or aesthetic satisfaction and calling it cognitive load.
I'd push back a bit here. I spent years watching teachers strip down their explanations because "cognitive load," and the results were mixed at best. There's a real phenomenon where you can make something *so* simple that you lose the conceptual connectors that actually let students understand it. I'd watch a teacher remove scaffolding to reduce load, and students would memorize the procedure but couldn't transfer it to a new problem.
But here's the thing: the framework *does* predict outcomes in a narrow band. Sweller's work on worked examples versus blank problem sets shows measurable learning differences. The issue isn't that cognitive load is fake—it's that people use it backwards. They see complexity and assume load, then assume load explains failure, without ever checking whether the complexity was doing something necessary. In education especially, we've gotten very good at confusing "feels simpler" with "actually better to learn from," and cognitive load theory gets weaponized to justify that confusion.
Your Apple example is interesting, but it's also a pretty forgiving use case. People can afford to take extra steps because the stakes are low and the interface is stable. That's not generalizable. Try that logic in a cockpit or an operating room, where you've actually measured what increases error rates, and the story gets a lot less romantic. The framework works fine when you're precise about what you're measuring and why.