---
title: "Cognitive Load"
source: "/reference/cognitive-load"
description: "Every task consumes limited mental resources; interface complexity adds cost when users must remember, infer, translate, compare, or recover information unnecessarily."
---
# Cognitive Load
Every task consumes limited mental resources; interface complexity adds cost when users must remember, infer, translate, compare, or recover information unnecessarily.
### Principle
Every task consumes limited mental resources; interface complexity adds cost when users must remember, infer, translate, compare, or recover information unnecessarily.
### Why it matters
Cognitive load is a useful umbrella for many UX failures. Extra load appears when labels are unclear, state is hidden, similar concepts use different terms, users must remember values between steps, or the interface asks them to solve organizational problems that the system could solve. Complexity can be inherent to the work. Layr should target avoidable mental effort rather than attempting to make every advanced workflow simple.
### Deeper design interpretation
Cognitive load becomes a UX problem when the interface consumes mental effort that does not belong to the user's actual goal. The user may already be performing demanding work: reconciling financial records, mapping data, configuring infrastructure, or evaluating risk. Every unclear label, hidden state, repeated calculation, unexplained dependency, or context switch adds another problem on top of the domain problem.
The goal is therefore not to make complex work appear simple. Hiding information can increase uncertainty and force the user to remember more. Effective design moves mechanical work into the system while keeping decision-relevant context visible.
Layr should distinguish intrinsic task complexity from interface-added complexity. This distinction prevents superficial recommendations such as removing fields that are required for a correct decision.
### What the agent should reason about
Trace what the user must remember, infer, translate, calculate, compare, or recover at each step. If the system already holds that information, ask whether it can be displayed, derived, grouped, or safely automated.
The agent should pay attention to compound costs. Several individually small frictions can become significant when they occur in the same workflow or repeat frequently.
### Common failure patterns
- Internal terminology forces users to translate between product language and domain language.
- Required comparison values are separated across tabs or screens.
- Users re-enter information the system already knows.
- Validation arrives late, forcing users to revisit earlier decisions.
- State must be reconstructed from several independent badges and logs.
### Audit questions
- What mental work belongs to the user's domain task, and what work was introduced by the interface?
- Which facts must be remembered instead of remaining visible?
- Could the system derive or preserve any of the required information safely?
- Does removing information actually reduce effort, or does it merely hide context?
### Example agent finding
> **High — Field mapping requires unnecessary recall across screens.** The destination mapping view omits source examples, so users must remember the values seen on the previous step while choosing a target field. Display the source name, representative values, destination candidate, and confidence together at the mapping decision.
### Agent directive
> Find avoidable mental work introduced by the interface. Preserve domain complexity that is necessary for a correct decision.
### Apply this when
- Multi-step tasks, forms, enterprise tools, configuration, data analysis, onboarding, checkout, and error recovery.
### Observable signals
- Users must remember information from a previous screen to complete the current one.
- Labels require interpretation because they expose internal implementation terminology.
- Equivalent concepts use inconsistent names.
- Several decisions are presented before users have the information needed to make them.
- Status, progress, or validation must be mentally reconstructed from scattered cues.
### Recommended actions
- Keep required context visible at the point of decision.
- Use domain language users recognize and define unavoidable technical terms.
- Remove redundant choices and duplicate inputs.
- Break long tasks into coherent stages when sequencing reduces simultaneous reasoning.
- Use sensible defaults and derived values when they are safe and transparent.
### Do not over-apply
Do not remove information solely to make a screen look simpler. Hiding necessary context can increase memory burden and uncertainty.
### Example
**Weak:** A migration review asks users to choose field mappings while the source field examples are available only on the previous screen.
**Stronger:** Source field, sample values, destination field, and confidence are visible together at the mapping decision.
### Evaluation notes
- **Default severity:** Medium to high depending on task consequence and frequency.
- **Typical confidence:** High for forced recall or redundant steps; medium for inferred mental effort.
- **Primary evidence:** Task flow, screen transitions, required inputs, terminology, visible context.
- **Related rules:** Working Memory, Chunking, Hick's Law, Tesler's Law
### References
- [Laws of UX — Cognitive Load](https://lawsofux.com/cognitive-load/)
## Related rules
- [Working Memory](/__layr/pages/reference/working-memory.md)
- [Chunking](/__layr/pages/reference/chunking.md)
- [Hick's Law](/__layr/pages/reference/hicks-law.md)
- [Tesler's Law](/__layr/pages/reference/teslers-law.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Memory & Cognition.
## Retrieve
- Canonical page: https://layr.design/reference/cognitive-load
- Markdown for agents: https://layr.design/__layr/pages/reference/cognitive-load.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "cognitive-load"
title: "Cognitive Load"
category: "Memory & Cognition"
origin: established
canonical_url: "https://layr.design/reference/cognitive-load"
principle: "Every task consumes limited mental resources; interface complexity adds cost when users must remember, infer, translate, compare, or recover information unnecessarily."
directive: "Find avoidable mental work introduced by the interface. Preserve domain complexity that is necessary for a correct decision."
applies_when:
- "Multi-step tasks, forms, enterprise tools, configuration, data analysis, onboarding, checkout, and error recovery."
observable_signals:
- "Users must remember information from a previous screen to complete the current one."
- "Labels require interpretation because they expose internal implementation terminology."
- "Equivalent concepts use inconsistent names."
- "Several decisions are presented before users have the information needed to make them."
- "Status, progress, or validation must be mentally reconstructed from scattered cues."
audit_questions:
- "What mental work belongs to the user's domain task, and what work was introduced by the interface?"
- "Which facts must be remembered instead of remaining visible?"
- "Could the system derive or preserve any of the required information safely?"
- "Does removing information actually reduce effort, or does it merely hide context?"
recommended_actions:
- "Keep required context visible at the point of decision."
- "Use domain language users recognize and define unavoidable technical terms."
- "Remove redundant choices and duplicate inputs."
- "Break long tasks into coherent stages when sequencing reduces simultaneous reasoning."
- "Use sensible defaults and derived values when they are safe and transparent."
avoid_when:
- "Do not remove information solely to make a screen look simpler. Hiding necessary context can increase memory burden and uncertainty."
common_failure_patterns:
- "Internal terminology forces users to translate between product language and domain language."
- "Required comparison values are separated across tabs or screens."
- "Users re-enter information the system already knows."
- "Validation arrives late, forcing users to revisit earlier decisions."
- "State must be reconstructed from several independent badges and logs."
evidence_types:
- "Task flow"
- "screen transitions"
- "required inputs"
- "terminology"
- "visible context"
default_severity: "Medium to high depending on task consequence and frequency."
typical_confidence: "High for forced recall or redundant steps; medium for inferred mental effort."
related_rules:
- { id: "working-memory", title: "Working Memory", url: "https://layr.design/reference/working-memory" }
- { id: "chunking", title: "Chunking", url: "https://layr.design/reference/chunking" }
- { id: "hicks-law", title: "Hick's Law", url: "https://layr.design/reference/hicks-law" }
- { id: "teslers-law", title: "Tesler's Law", url: "https://layr.design/reference/teslers-law" }
```
## What to reason about
Trace what the user must remember, infer, translate, calculate, compare, or recover at each step. If the system already holds that information, ask whether it can be displayed, derived, grouped, or safely automated. The agent should pay attention to compound costs. Several individually small frictions can become significant when they occur in the same workflow or repeat frequently.
## Routing
Route a review here when the user must remember, infer, translate, reconcile, or reconstruct information. These rules are especially relevant when the system already possesses context that the interface fails to expose.
## Review procedure
For every finding:
1. Identify the exact component, state, route, or interaction.
2. State the observable evidence.
3. Name the principle that applies.
4. Explain the user consequence in the current context.
5. Estimate severity from the consequence, frequency, and reversibility.
6. Recommend the smallest change that addresses the issue while preserving the product's existing design system.
7. Lower confidence when intent, frequency, audience, device, or product constraints must be inferred.
8. Do not produce generic advice such as "improve hierarchy" or "make this clearer" without specifying what is wrong and why.
## Finding contract — emit exactly this shape
```yaml
finding:
rule_id: string
location: string
evidence:
- observable fact
impact: string
severity: low | medium | high | critical
confidence: low | medium | high
recommendation:
change: string
rationale: string
preserve:
- existing design-system behavior
- valid product constraints
```
## Example finding for this rule
High — Field mapping requires unnecessary recall across screens. The destination mapping view omits source examples, so users must remember the values seen on the previous step while choosing a target field. Display the source name, representative values, destination candidate, and confidence together at the mapping decision.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html
ImportStep 3 of 4 · Map fields
Map fields
cust_id_v2no sample→Choose field ⌄
crtd_tsno sample→Choose field ⌄
ContinueSample values are on the previous screen
```
```html
ImportStep 3 of 4 · Map fields
Map fields
customer_idAC-1042→Account ID99%
created_at16 Sep 2026→Created date98%
Confirm mappingSource, sample, destination and confidence in one view