Designing for Cognitive Load, Not Just Pretty Layouts

We talk about web pages the way we talk about paintings: composition, color, whitespace, taste. But a visitor doesn’t experience your page as a painting. They experience it as a task. They arrived wanting something, and the page is a series of small mental operations standing between them and it. Read this. Ignore that. Decide between these. Remember what you saw two screens ago. Each operation costs a little thinking, and the visitor pays out of a budget you can’t see.

That budget is what people mean by cognitive load, and I’ve come to believe it’s the most neglected dimension of web design, partly because it’s invisible in a screenshot. A screenshot shows you whether a page is pretty. It cannot show you whether the page is exhausting, because exhaustion happens over time, in a mind, as it tries to do something. Two pages can look nearly identical and differ enormously in how much they demand. One has a single obvious next step; the other has four plausible ones, and the visitor must first do the work of figuring out which is really the one you meant.

The accessibility framing matters here, and I want to make it precise rather than pious. A large number of people have conditions that shrink the budget directly: ADHD, dyslexia, brain injury, dementia, anxiety. WCAG’s guidance about consistent navigation, clear labels, and helping users avoid and correct errors is substantially about them. But cognitive load is unusual among accessibility topics in that the budget also shrinks temporarily, for everyone. A parent filling out your form while holding a toddler has, functionally, a cognitive disability for those three minutes. So does someone in a hospital waiting room, or on their fourth video call of the day, or just tired. Design that respects a permanently small budget also respects a temporarily small one, and temporarily small budgets are the normal condition of your customers, not the exception.

So where does the budget actually go? Mostly to three things, in my experience of auditing pages. It goes to choices: every additional option on a screen is a decision the visitor must make or actively suppress, and unlike you, they don’t know which options are safe to ignore. It goes to memory: any time a page requires holding information from one step to use in another, comparing plans that aren’t shown side by side, remembering an error message after the page reloaded and cleared it, the visitor is doing unpaid clerical work in their head. And it goes to inconsistency: when the same action looks different in different places, or the button that was on the left is now on the right, the visitor has to re-derive the interface instead of reusing what they already learned. None of these costs appear in a design review, because the reviewer already knows the answers. Cognitive load is only visible from the outside of the knowledge.

That last point deserves a name: the builder’s discount. You built the page, so you read it for free. You know the checkout has three steps, so the unlabeled progress dots make sense to you. You know “Solutions” in your nav means “products,” so the euphemism costs you nothing. Every hour you spend with your own site makes you less able to feel what it costs a stranger, which is why teams sincerely believe their exhausting pages are simple. This is also why I built scanning into GazeSite rather than relying on self-assessment; the useful question is never “does this make sense,” it’s “does this make sense to someone spending their own budget, not yours.”

What does spending less look like in practice? Not minimalism, exactly. A sparse page can be expensive if the sparseness deletes information the visitor needs, forcing them to click around and hold the pieces in memory. The cheap page is the one that answers the visitor’s next question right where the question occurs. Say what happens before the visitor commits: what the button does, what the form needs, what an error means and how to fix it, stated next to the field that caused it. Prefer recognition over recall, showing the choice rather than asking the visitor to remember it. Front-load sentences so the point arrives before the qualifications. Keep one primary action per screen and visibly demote the rest. Each of these is small. Together they change whether finishing the task feels like walking downhill or uphill.

And the slope is the business outcome. A visitor who runs out of budget doesn’t file a complaint about your information architecture. They just stop, mid-form, mid-comparison, mid-scroll, and the analytics record it as a drop-off with no stated reason. Almost by definition, cognitive overload never shows up in feedback: the overloaded user is precisely the one without energy left to explain. So the losses stay unattributed, and the redesign budget goes to making the page prettier, which was never the problem. The page was already pretty. It was just expensive, and your customers, quietly, one by one, declined to pay.