Every interface asks something of the user's mind. Cognitive load is the measure of that demand — the total mental effort required to understand and operate an interface. John Sweller's Cognitive Load Theory, developed in the late 1980s and published systematically in 1988, identified three distinct types: intrinsic load (the inherent complexity of the task itself), extraneous load (complexity added by poor design), and germane load (the mental work of building understanding and skill). Designers cannot reduce intrinsic load without changing the task. They can and must reduce extraneous load.
The Psychology
The distinction matters because intrinsic load is legitimate. Filing a tax return is cognitively demanding because tax is genuinely complex. A well-designed tax application cannot make that complexity disappear, but it can avoid adding to it with confusing layouts, unclear labels, inconsistent terminology, and poor error handling. Extraneous load is waste. Every visual element that does not contribute meaning, every interaction step that does not move the user toward their goal, every label that requires interpretation rather than simply reading — these are all extraneous load that good design eliminates. Germane load, meanwhile, is the useful cognitive work of actually learning how a system works — tutorials, onboarding, and progressive disclosure all support this productively.
In Product Design
Concrete examples of high extraneous load are easy to find: forms with unlabelled fields or labels positioned far from their inputs, navigation structures that require users to hold context about where they are in a hierarchy, dashboards that present every metric at equal visual weight so nothing can be prioritised, error messages that name the error code but do not explain what the user should do. These are all design decisions that add cognitive burden without adding value. Compare them to interfaces that use progressive disclosure to surface only relevant options, that use inline validation to catch errors in the moment rather than after submission, or that use consistent icon families so learned patterns transfer across the product.
How to Apply It
The practical techniques for reducing cognitive load are well established. Use familiar patterns wherever possible — do not invent a new way to do something if a standard pattern already works. Group related information and separate unrelated information so the structure does the cognitive work of organisation. Use visual hierarchy to communicate what matters most so users do not have to decide what to focus on. Reduce the number of active choices on any given screen. Write in plain language: every word that requires interpretation is a micro-tax on attention. Test with real users and watch where they pause, re-read, or backtrack — these are the moments of excess cognitive load.
Why It Matters
When cognitive load is too high, users do not push through by concentrating harder. They give up, make errors, or disengage. High bounce rates on complex pages, low form completion rates, and support tickets asking "how do I do X" are all signals that cognitive load is exceeding what users are willing to spend on your interface. The goal is not to make everything effortless — some tasks require effort. The goal is to ensure that every unit of effort a user expends is spent on the task itself, not on deciphering the design.
