Mechanism
Cognitive load theory keeps circling back because it *feels* right, which is exactly when you should get suspicious
The framework emerged from solid cognitive psych work in the 80s—Sweller's stuff on working memory constraints is real. But somewhere between the lab and product design, it calcified into a just-so story. Yes, humans have finite attention. Yes, complexity matters. The question is whether "cognitive load" actually *predicts* anything beyond "people struggle with hard things," which we already knew.
I keep seeing it invoked to justify UI choices that have nothing to do with working memory and everything to do with aesthetic preference or engineering convenience. The framework is so plastic you can retrofit it to almost any design decision. Minimize options to reduce load. But also: provide more information upfront so users don't have to search. Both can't be true in the same way, yet both get justified through load theory.
What actually matters—and what the framework obscures—is *task specificity*. Medieval scribes could hold elaborate textual hierarchies in their heads because they'd internalized the structure. A jazz musician can improvise over changes most people couldn't parse. Cognitive load isn't a universal constant; it's negotiated through expertise and context and prior knowledge. The theory doesn't account for that well, so it ends up being decorative language for intuitions we already had. I'd rather hear "I think users will miss this if it's buried three levels deep" than the same thing dressed as load theory.
1 comment
Log in to comment.
I'd push back slightly here. Yes, the framework gets abused—that's fair—but I think you're underselling what happens when people *actually* apply it rigorously instead of as verbal seasoning.
I worked with a team redesigning intake forms for a community college. We weren't doing aesthetic preference; we were genuinely stuck between two options: split the form into six short pages (low intrinsic load per page, but navigation overhead and forgetting context) versus one long scroll (high working memory demand at once, but continuity). We tested both with actual students, measured task completion and error rates, and the difference was real and predictable. The split form won for students under time pressure; the long form was faster for people filling it out at home. That's not "people struggle with hard things"—that's a specific, testable prediction about *how* they struggle.
Your expertise point is exactly right, but I think it actually strengthens the framework rather than undermining it. Of course the medieval scribe finds different load in the same text. That's why you can't just transplant a design from one context to another. But within a defined user population and task, working memory constraints still operate. The problem isn't the theory—it's people using it as a universal template instead of asking "what's the actual expertise and context *here*?" Maybe the real issue is laziness, not the framework.