Cognitive Load Pass

---
name: Cognitive Load Pass
description: Structured review of a UI flow against five cognitive-load lenses, producing specific cuts.
when_to_use: User shares a flow, form, onboarding, or dashboard and asks "is this too much" or "help me simplify this".
---

# Cognitive Load Pass

## What this skill does
Walks a flow through five cognitive-load lenses — decisions, jargon, hidden state, memory load, and sequence dependencies — and returns specific cuts, not vague advice. Designed for flows where a non-technical user might quietly give up.

## When to load this skill
Load when the user describes or pastes a multi-step flow (sign-up, checkout, onboarding, form, settings panel, dashboard) and asks anything like "is this too much", "help me simplify", "why do users bounce here", "review for complexity", or "the team thinks this is fine but I don't".

## The procedure

### Step 1 — Map the flow before reviewing it
Before any analysis, restate the flow as a numbered list of screens or steps. If the user pasted a single screen, list every visible field, button, and label. If they described a multi-screen flow, list each screen's purpose in one sentence. This map is what every later lens operates on. If Claude can't produce a clean map, the user hasn't given enough information — ask once.

### Step 2 — Lens one: decisions
Count every decision the user has to make. A decision is any moment the interface asks "which of these do you want" — dropdowns, radio groups, checkboxes, branching questions, optional vs required fields, tier selection. Each one is a load. List them, count them, and flag any decision that could be: defaulted (pick a sensible default), deferred (ask later, after value is proven), deleted (the user doesn't actually need to decide), or merged (combine with an adjacent decision).

### Step 3 — Lens two: jargon density
Scan every user-facing string for jargon. Jargon is any word a non-technical user would need to Google. Industry terms, product-specific nouns, acronyms, English words used in a narrow technical sense ("provision", "instance", "workspace", "seat"). Count them. For each, propose a plain-language replacement. If the term is load-bearing and can't be replaced, add a one-sentence plain-English gloss next to it.

### Step 4 — Lens three: hidden state and memory load
Ask: what does the user have to remember from the previous screen to understand this one? What state is hidden (the selection they made earlier, the plan they're on, the email they typed)? Every hidden piece is a load. Fixes: show the state (breadcrumbs, summary panels, persistent chips), or remove the need for it entirely.

### Step 5 — Lens four: sequence dependencies
Ask: does this step only work if previous steps were done in a specific order? Sequence dependencies punish users who come in sideways — from a direct link, from back-button, from a bookmark. List every step that will break or confuse if approached out of order. Propose either: make the step order-independent, or gate it explicitly with a friendly message that explains what's missing.

### Step 6 — Write the cut list
Close with a numbered cut list, ranked by estimated load reduction. Each entry: one sentence describing the cut, what lens it came from, and the expected effect ("removes one decision", "removes two jargon terms", "eliminates hidden-state lookup"). No more than ten cuts — if you find more, bucket the overflow into "further investigation". This forces prioritization and respects the designer's limited attention.

## A worked example

**User:** Our new signup flow. Four screens: 1) email + password, 2) "choose your workspace type" (personal / team / enterprise), 3) "pick a plan" (free / pro / business), 4) "invite teammates" (optional). Users bounce hard at screen 2.

**Claude:** Mapping: four screens, three decisions, one optional action. Running five lenses.

**Decisions (5 total):** email, password, workspace type, plan tier, teammate emails. Screen 2's "workspace type" is the heaviest — three options with no visible difference to a new user. Cut: default everyone to "personal" and offer an "upgrade to team" action later, after they've done one thing successfully.

**Jargon (4 terms):** "workspace", "tier", "provision", "seat". Replacements: "project", "plan", "set up", "person". "Workspace type" becomes "Who's this for?" with two options ("Just me" / "Me and my team") — personal becomes the default, enterprise moves to sales contact.

**Hidden state:** screen 3 asks users to pick a plan without showing what each plan unlocks in terms of the workspace type they picked on screen 2. Two-screen memory load. Fix: show a one-line summary of the previous choice at the top of screen 3, or merge screens 2 and 3.

**Memory load:** users are asked to type an email on screen 1 and remember it to verify on a later screen. Standard pattern, acceptable load. No cut.

**Sequence dependencies:** screen 4 (invite teammates) only makes sense if the user picked "team" on screen 2. For "just me" users, it's noise. Fix: skip screen 4 entirely for personal users. Don't show them a step they'll just dismiss.

**Cut list (ranked):**
1. Default workspace type to "personal" and remove the screen. -1 decision, -2 jargon terms. Biggest win.
2. Rename remaining screens in plain language per the jargon pass. -2 jargon terms.
3. Skip "invite teammates" for solo users. -1 optional step, removes sequence dependency.
4. Show previous-choice summary on plan screen. Eliminates hidden state.

Expected result: 4 screens become 2 for solo users, 3 for team users. Bounce rate on the old screen 2 disappears because the screen is gone.

**User:** What about the enterprise tier?

**Claude:** Moves to a "Contact sales" link in the footer of the plan screen. Enterprise buyers are not this flow's audience — they're a sales conversation. Including them here costs every single self-serve signup a decision they don't need.

## What this skill will NOT do
- Will NOT return "consider simplifying" or other verdicts without specific cuts.
- Will NOT invent data about user behavior ("users love this"). If the user hasn't shared analytics, Claude stays descriptive.
- Will NOT replace user research. Cognitive-load analysis predicts friction; it doesn't measure it. The skill says so.
- Will NOT cut things that are load-bearing for legal, safety, or accessibility reasons without flagging the tradeoff explicitly.
- Will NOT produce more than ten cuts. If more are tempting, it buckets the overflow.