---
title: "Working Memory"
source: "/reference/working-memory"
description: "Working memory temporarily holds and manipulates information needed for the task currently in progress."
---
# Working Memory
Working memory temporarily holds and manipulates information needed for the task currently in progress.
### Principle
Working memory temporarily holds and manipulates information needed for the task currently in progress.
### Why it matters
Working memory is consumed when users compare options, transform values, remember instructions, track selections, or maintain context across screens. Interfaces can reduce that burden by keeping information visible and externalizing state. This is particularly important for unfamiliar, interrupted, mobile, or high-stakes tasks.
### Deeper design interpretation
Working memory supports the active manipulation of information during a task. It is consumed by comparison, sequencing, calculation, temporary state, and interruption recovery. Interfaces reduce this cost when they externalize state: selected items remain visible, totals are calculated, prior values persist, and users can review what has already been decided.
This matters particularly in mobile contexts, unfamiliar workflows, long-running tasks, and high-stakes operations. Interruptions are common, screens are smaller, and the cost of losing context is higher.
Layr should treat hidden state as a potential memory tax. When the product already knows the current selection, previous step, calculation, or job status, making the user reconstruct it is usually unnecessary.
### What the agent should reason about
Trace dependencies across time and views. If a later action requires information that is currently hidden, determine whether the system can safely persist and present it. Consider privacy before recommending persistent display of sensitive data.
A strong finding often links hidden state directly to an error mode: duplicate selection, wrong comparison, forgotten filter, repeated work, or inability to resume.
### Common failure patterns
- Multi-select state disappears when users paginate.
- A confirmation view omits the details needed to verify the action.
- Filters reset when navigating to an item and back.
- Users manually total values that the interface already has.
- Draft state exists server-side but the UI does not indicate that it was saved.
### Audit questions
- Which facts does the system already know that the user is being asked to remember?
- What happens after interruption or navigation?
- Can users verify accumulated state before committing?
- Would persistent context create privacy or clutter concerns that require a different presentation?
### Example agent finding
> **High — Bulk selection is invisible across pagination.** Users can select records on several pages, but the table shows neither a persistent count nor a review list. Preserve selection state and expose a reviewable summary before the bulk action so users do not have to remember what is included.
### Agent directive
> Externalize task state whenever the system already knows it. Do not require users to remember information that can be shown, preserved, or derived safely.
### Apply this when
- Multi-step forms, migrations, checkout, comparison, configuration, scheduling, data entry, code/OTP flows, and interrupted tasks.
### Observable signals
- A later step depends on values shown only earlier.
- Selections disappear when a panel closes even though they are still active.
- A summary omits information required to verify the final action.
- Users must manually total, compare, or reconcile values the system already has.
- Returning after interruption provides no indication of prior progress.
### Recommended actions
- Show persistent summaries and selected state.
- Carry forward safe values and provide review before commitment.
- Place comparison values side by side.
- Save progress where appropriate and make restoration visible.
- Provide copy, reveal, or history affordances for temporary values.
### Do not over-apply
Persistent context can create clutter or privacy concerns. Show what is needed for the current task and protect sensitive data appropriately.
### Example
**Weak:** A user selects five records across paginated pages, but the interface shows no persistent selection count or list.
**Stronger:** The selection state remains visible, can be reviewed, and survives pagination until the user clears or completes the action.
### Evaluation notes
- **Default severity:** Medium to high depending on error cost.
- **Typical confidence:** High when the interface requires recall across time or views.
- **Primary evidence:** State persistence, summaries, screen transitions, hidden selections, task dependencies.
- **Related rules:** Cognitive Load, Chunking, Miller's Law, Zeigarnik Effect
### References
- [Laws of UX — Working Memory](https://lawsofux.com/working-memory/)
## Related rules
- [Cognitive Load](/__layr/pages/reference/cognitive-load.md)
- [Chunking](/__layr/pages/reference/chunking.md)
- [Miller's Law](/__layr/pages/reference/millers-law.md)
- [Zeigarnik Effect](/__layr/pages/reference/zeigarnik-effect.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/working-memory
- Markdown for agents: https://layr.design/__layr/pages/reference/working-memory.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "working-memory"
title: "Working Memory"
category: "Memory & Cognition"
origin: established
canonical_url: "https://layr.design/reference/working-memory"
principle: "Working memory temporarily holds and manipulates information needed for the task currently in progress."
directive: "Externalize task state whenever the system already knows it. Do not require users to remember information that can be shown, preserved, or derived safely."
applies_when:
- "Multi-step forms, migrations, checkout, comparison, configuration, scheduling, data entry, code/OTP flows, and interrupted tasks."
observable_signals:
- "A later step depends on values shown only earlier."
- "Selections disappear when a panel closes even though they are still active."
- "A summary omits information required to verify the final action."
- "Users must manually total, compare, or reconcile values the system already has."
- "Returning after interruption provides no indication of prior progress."
audit_questions:
- "Which facts does the system already know that the user is being asked to remember?"
- "What happens after interruption or navigation?"
- "Can users verify accumulated state before committing?"
- "Would persistent context create privacy or clutter concerns that require a different presentation?"
recommended_actions:
- "Show persistent summaries and selected state."
- "Carry forward safe values and provide review before commitment."
- "Place comparison values side by side."
- "Save progress where appropriate and make restoration visible."
- "Provide copy, reveal, or history affordances for temporary values."
avoid_when:
- "Persistent context can create clutter or privacy concerns. Show what is needed for the current task and protect sensitive data appropriately."
common_failure_patterns:
- "Multi-select state disappears when users paginate."
- "A confirmation view omits the details needed to verify the action."
- "Filters reset when navigating to an item and back."
- "Users manually total values that the interface already has."
- "Draft state exists server-side but the UI does not indicate that it was saved."
evidence_types:
- "State persistence"
- "summaries"
- "screen transitions"
- "hidden selections"
- "task dependencies"
default_severity: "Medium to high depending on error cost."
typical_confidence: "High when the interface requires recall across time or views."
related_rules:
- { id: "cognitive-load", title: "Cognitive Load", url: "https://layr.design/reference/cognitive-load" }
- { id: "chunking", title: "Chunking", url: "https://layr.design/reference/chunking" }
- { id: "millers-law", title: "Miller's Law", url: "https://layr.design/reference/millers-law" }
- { id: "zeigarnik-effect", title: "Zeigarnik Effect", url: "https://layr.design/reference/zeigarnik-effect" }
```
## What to reason about
Trace dependencies across time and views. If a later action requires information that is currently hidden, determine whether the system can safely persist and present it. Consider privacy before recommending persistent display of sensitive data. A strong finding often links hidden state directly to an error mode: duplicate selection, wrong comparison, forgotten filter, repeated work, or inability to resume.
## 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 — Bulk selection is invisible across pagination. Users can select records on several pages, but the table shows neither a persistent count nor a review list. Preserve selection state and expose a reviewable summary before the bulk action so users do not have to remember what is included.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html