Working Memory

Working memory temporarily holds and manipulates information needed for the task currently in progress.

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.

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.

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.

• 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.

• 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?

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.

Externalize task state whenever the system already knows it. Do not require users to remember information that can be shown, preserved, or derived safely.

• Multi-step forms, migrations, checkout, comparison, configuration, scheduling, data entry, code/OTP flows, and interrupted tasks.

• 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.

• 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.

Persistent context can create clutter or privacy concerns. Show what is needed for the current task and protect sensitive data appropriately.

• 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