What is cognitive load?

In short

Anyone looking at a screen carries a goal in their head. The screen itself also asks them to read, remember and decide. The sum of these demands is the cognitive load.

When the load exceeds what the person can carry, the work slows down. I see this most often in forms: every unclear field loads one more small decision onto the person.

Compare two versions of the same form in the demo below. The counter shows how many decisions you make in each version.

What is cognitive load?

In her article of December 22, 2013, Kathryn Whitenton of Nielsen Norman Group defines cognitive load as the amount of mental resources required to operate a system. Informally, the article calls this “brain power”. More formally, it means slots in working memory.

According to the article, performance drops when incoming information exceeds this capacity. Understanding takes longer, and important details get missed. The person can become overwhelmed and give up.

Whitenton notes something else: unlike a computer, there is still no way to increase the brain’s actual processing power. That is why I focus on reducing the load on the design side.

Laws of UX defines cognitive load similarly: the mental resources needed to understand and interact with an interface. The same page sees the term as closely tied to Miller’s law.

Sweller’s cognitive load theory

The theory comes from educational psychology. According to Wikipedia, educational psychologist John Sweller developed cognitive load theory in the late 1980s. The starting point was a study of problem solving.

The foundational paper is John Sweller’s “Cognitive Load During Problem Solving: Effects on Learning”. It appeared in April 1988 in the journal Cognitive Science: volume 12, issue 2, pages 257–285.

According to Laws of UX, the theory extends George Miller’s information processing theories. I describe Miller’s limit on short-term memory on a page of its own.

For the distinction between intrinsic and extraneous load, the Wikipedia article points to the 1991 paper by Paul Chandler and Sweller. It is in volume 8 of the journal Cognition and Instruction (issue 4, pages 293–332).

The same article names a third type: germane load. It means the effort that goes into building lasting knowledge. According to the article, this load comes from the learner’s characteristics.

The theory was developed for teaching. The NN/g article carries the same distinction over to interface design.

Intrinsic and extraneous load

For interfaces, the NN/g article distinguishes two types. Users come to learn something or to get a task done. Part of the load this task brings is unavoidable.

Type of load	NN/g definition	In the form
Intrinsic load	The effort of absorbing new information and keeping track of one’s own goals.	Knowing the delivery address, choosing the right phone number. This load is the task itself.
Extraneous load	Processing that takes up mental resources but doesn’t help users understand the content.	Guessing what goes in the “Code” field, typing the same address a second time.

The definitions are summarised from the NN/g article; the examples are mine.

Whitenton’s example is planning a vacation. Someone looking for a vacation keeps information about the interface and their own constraints, such as price or dates, in their head at the same time. The article doesn’t assign these constraints to a type. I read them as intrinsic load, because the design can’t remove the price.

As an example of extraneous load, the article names type styles that carry no meaning. Designers should eliminate this load, or at least minimise it.

Live demo: the same form, two loads

Below is the delivery form of a made-up online store. The high-load version has unnecessary fields and unclear labels, and the layout has two columns. In the low-load version, you complete the same task in one column, with explanatory labels.

Switch between the two versions with the toggle at the top. In the high-load version, choose Business under “Invoice type”: only then do the business fields open. In the low-load version, untick “My billing address is the same as my delivery address” and see how the counter changes.

The same form, two loads

High-load version: delivery details

This version has 18 fields and 23 decisions. 15 decisions come from unnecessary fields, unclear labels or missing defaults. If Business is chosen as the invoice type, 3 more fields open.

TitlePlease chooseMs.Mr.Mx.Dr.1 decision: unnecessary field

First name1 decision

Last name1 decision

Date of birth1 decision: unnecessary field

Tel2 decisions: which number, which format?

Tel 22 decisions: unnecessary and unclear

Email1 decision

Email (repeat)1 decision: unnecessary repeat

Address1 decision

Address 22 decisions: what goes here?

ZIP code1 decision

City and state1 decision

County2 decisions: why does the store need this?

Invoice type

PersonalBusiness

1 decision: no preselection

Company name1 decision

Tax ID (EIN)1 decision

Contact person1 decision

Billing address1 decision: the same address again

Billing ZIP code1 decision: the same ZIP code again

Billing city and state1 decision: the same city again

Code2 decisions: which code?

Low-load version: delivery details

This version has 7 fields and 7 decisions. If the billing address is different, 3 more fields open.

Full name

This name goes on the package label.

1 decision

Mobile number

The carrier calls this number before delivery. Example: (555) 123-4567

1 decision

Email

We send the order summary to this address.

1 decision

Street address

For example, 123 Main St.

1 decision

City1 decision

State1 decision

ZIP code1 decision

My billing address is the same as my delivery address

Billing address

Street address.

1 decision

Billing ZIP code1 decision

Billing city and state1 decision

The form is made up and isn’t sent anywhere. The number of decisions follows my counting rule and isn’t a measured value: each field is one decision, an unclear label adds another, and accepting a default doesn’t count. Pink labels show avoidable decisions.

Both versions take the same order; the difference lies in the number of decisions. In the high-load version, 15 of 23 decisions are avoidable. If you choose a business invoice, 3 fields and 3 decisions are added, but those decisions are the task itself.

I didn’t count the two-column layout. Even so, I often see users hesitate in audits while looking for the next field. In the demo, the form becomes a single column at phone width anyway.

Ways to reduce cognitive load

The NN/g article names three ways. I explain each with a form example.

Avoid visual clutter

According to the article, unnecessary links, irrelevant images and meaningless typographic flourishes slow users down. Whitenton adds that meaningful elements are valuable. The problem begins when they are overused.

In a form, the equivalent is fields with no use, such as “Tel 2” or “Date of birth”. The person pauses before each field and wonders whether they have to fill it in.

Build on existing mental models

Users recognise labels and layouts they have learned on other websites. If you use them, users have less to learn on your website. More on this on the pages about Jakob’s law and the mental model.

Offload tasks

According to the article, for every element that requires reading, remembering or a decision, look for an alternative. Its suggestions: show a picture, re-display information already entered, or set a smart default.

The “My billing address is the same as my delivery address” box in the demo is an example. The person doesn’t retype three fields; they accept a single default.

The number of options is a decision load too. How decision time grows with more options is described by Hick’s law.

The article also writes that most of NN/g’s leading usability guidelines aim to reduce cognitive load. Chunking content and shortening response times are examples.

Limits and misconceptions

Intrinsic load can’t be reduced to zero. By NN/g’s definition, it arises because the person takes in information and pursues their goal. You can’t cut a loan application down to two fields. The aim is not to add more load than the task requires.

The theory was developed for learning. The very title of Sweller’s 1988 paper speaks of problem solving and learning. In the interface, I use these terms as a thinking tool.

The types may not simply add up. The Wikipedia article reports research suggesting that the three types may overlap, which questions the assumption that they are additive.

Few fields don’t always mean low load. “Full name” in the demo is a single field. But if the system behind it expects first and last names separately, the person later runs into an error message. The saved load comes back.

My note

The extraneous load I see most often in audits is labels that don’t say what they want. A field with only “Code” or “Type” above it stops the person. A line of explanation under the label is usually enough.

In second place is repeated information. If the person types the same address twice, the system is asking for something it already knows. To find this, I fill in the form myself from start to finish and note every place where I hesitate.

I don’t sum up cognitive load in a single number. When I review a screen, I ask: is this decision the person’s task, or a side effect of our design? I ask this question of every field in a heuristic evaluation. Details on forms are in the form design pattern.

If you want someone from outside to ask this question of your own forms, take a look at the UX Audit.