Mechanism
Why we keep confusing capacity for architecture
Most people think cognitive load is about *how much* you can think about at once—like RAM in a computer. That's not quite right, and it matters because the folk version doesn't predict much of anything. What you actually want to know is why the same task feels trivial on Monday and impossible on Friday, and why your colleague can hold seven threads in her head while you're managing two. Capacity isn't the constraint. *Structure* is.
The framework came out of Chandler and Sweller's work on learning in the late 80s, and it was useful for a narrow problem: explaining why badly designed instructional materials fail. If you're trying to teach someone fractions while also making them parse confusing diagrams, you're fighting yourself. Fair enough. But the field got lazy. It became a post-hoc explanation for anything that felt cognitively hard, which meant it stopped predicting anything. You slap "high cognitive load" on a bad interface and move on. You could've just said "this doesn't work."
The predictive part only shows up when you get specific about *what kind* of load and *what prior knowledge* someone brings. A surgeon doing a complex procedure isn't cognitively overloaded in any meaningful sense—their schema is so well-developed that most of the work is automatic. Same total operations required; completely different load profile. If your framework can't distinguish between a novice accountant struggling with a spreadsheet and an expert finding it trivial, it's not doing work. It's just a feeling you're labeling.
I think there's something real underneath—something about working memory, pattern recognition, and how expertise restructures what counts as "simple." But the way people use "cognitive load" now is more diagnostic than explanatory. It's a red flag that says "look here, something's wrong with how this information is packaged"—which is fine, except then we stop looking. We need frameworks that predict *which changes* will actually help, not just ones that confirm something feels difficult.
4 comments
Log in to comment.
I'd bet this gets worse before anyone fixes it. The appeal of "cognitive load" as a catch-all is too strong—it's vague enough to work in any context, it sounds scientific, and it lets you feel like you've diagnosed something without actually having to design a solution. In education especially, once a concept gets that kind of rhetorical power, it tends to calcify.
What I'm predicting: we'll see a lot more intervention studies in the next five years claiming to "reduce cognitive load" by removing stuff from lessons or simplifying materials, and most of them will show modest or no effect because nobody's actually tracking what schema the learners bring or what they're automating. The studies will pile up looking inconsistent, people will blame implementation or sample size, and meanwhile the framework keeps its reputation intact because it was never falsifiable in the first place. The real work—actually mapping what makes something easier for different people with different prior knowledge—is harder and less publishable.
The irony is that the specific, useful claim ("badly designed materials create unnecessary processing") got buried under the vague one ("cognitive load is high"). A teacher I know ditched a confusing textbook diagram based on that narrow insight and it actually helped. But she could've just said "this doesn't work" and done the same thing.
The surgeon example is doing a lot of work here, and I think it's papering over something. Yes, expertise flattens load—but that's partly because surgeons have spent thousands of hours building schemas, and they're operating in a domain where the stakes force relentless feedback. You can't coast. Most people don't have that. So when someone tells me cognitive load theory is useless because an expert finds something easy, I ask: what's your actual intervention target? You can't tell someone "develop better schemas" and call it advice.
The real problem isn't that CLT became post-hoc. It's that people used it as permission to stop asking harder questions. Instead of "this interface has high cognitive load," you need "this interface requires holding X things in working memory while also pattern-matching against Y category sets that this user hasn't automated yet." That's specific. That predicts something. But it also requires you to actually know what someone knows, which is harder than measuring interface complexity.
In schools I'd see this constantly. A kid would struggle with a worksheet and teachers would say "cognitive overload" when the real issue was that we'd taught fractions in isolation, so the kid had no hooks to hang new procedures on. The load wasn't the problem—the *architecture* was, sure, but not the architecture of the page. The architecture of the prior curriculum. CLT became an excuse not to dig into that. So I'd say you're right that the framework got lazy, but maybe the fix is using it more carefully, not less. Though I grant that might just mean using it rarely.
The surgeon example is exactly right, but I think you're being too generous about the diagnostic move. Saying "cognitive load is high" doesn't even reliably flag the right problem—it just says *something* feels hard, which we already knew.
I watched this play out in a school that implemented a whole "reduce cognitive load" initiative. Teachers started eliminating steps from instructions, removing "distracting" visuals, simplifying worksheets. Some of it helped. A lot of it just made things shallower. A kid struggling with a multi-step word problem wasn't necessarily overloaded—she might've needed *more* structure, more worked examples, or more time thinking through why the steps mattered. Fewer steps on the sheet didn't help her schema develop. It just made the task simpler without making her smarter at it.
The real issue is that "cognitive load" has become a permission slip to redesign things without understanding what's actually hard about them. You need to know: Is this hard because it's genuinely novel? Because the prerequisite knowledge is missing? Because we're asking for automatic retrieval before the pattern is learned? Because the notation is genuinely confusing versus just unfamiliar? Those point to completely different fixes. But "reduce cognitive load" works as a vague solution to all of them, which is why it sticks around. It feels actionable without requiring you to actually diagnose anything.
The surgeon example is exactly right, and there's some solid data backing this up. Ericsson's work on expert memory shows that chess masters don't have bigger working memory—they recognize board patterns as single chunks instead of individual pieces. Same cognitive machinery, radically different functional capacity because the *structure* of what they know changed. A novice sees twelve pieces to track; the master sees "a weak kingside."
Where this breaks down in practice is that education keeps trying to apply cognitive load theory as a universal design principle instead of a diagnostic. We'll redesign a math textbook to "reduce load" by simplifying diagrams, but if the students don't have the schema to chunk the content in the first place, we've just made it shallower. You end up with materials that are easier to *process* but harder to *learn from*—because the struggle was doing some of the cognitive work that builds the schema. That's not a bug in the original design; it was the point.
The real prediction power shows up when you ask: does this person have the prior knowledge to handle this structure? If yes, simplifying it wastes time. If no, you need to build schema first, which isn't about load reduction at all—it's about sequencing and deliberate practice. But that's slower and messier than just flattening the interface, so we mostly don't do it.