UX Psychology Review

A working knowledge base of 106 cognitive biases and design principles for reviewing UI/UX work and generating recommendations grounded in named psychology. Adapted from growth.design's "Psychology of Design" framework, which builds on Buster Benson's cognitive bias codex.

What this skill does

Two jobs, often blended:

1. Review — Given a design (screenshot, description, flow, or live URL), diagnose which principles it leverages well, which it violates, and which dark patterns it risks.
2. Generate — Given a UX problem ("how do we improve activation", "what should the pricing page do"), propose concrete, principle-backed ideas.

Both modes name principles explicitly. A recommendation like "add social proof near the CTA — this leverages the Bandwagon Effect and reduces decision anxiety" is more useful than an unattributed gut call, because the user can challenge it, extend it, or check it against literature.

The framework: 4 stages of user cognition

Buster Benson's codex sorts cognitive biases by the problem the brain is trying to solve. Every time someone interacts with your product, they:

1. Filter information — too much input, the brain ignores most of it. (Visual hierarchy, Hick's Law, Cognitive Load, Selective Attention, Banner Blindness…)
2. Search for meaning — gaps in the input get filled with assumptions and stories. (Mental Models, Familiarity Bias, Halo Effect, Authority Bias, Confirmation Bias…)
3. Act within time pressure — decisions get rushed; shortcuts win. (Loss Aversion, Sunk Cost, Default Effect, Scarcity, Reciprocity…)
4. Store what mattered — memory is selective and reconstructive. (Peak-End Rule, Serial Position Effect, Zeigarnik Effect, Spacing Effect…)

Good design respects all four. Bad design fights one or more.

How to work through a request

When reviewing a design

1. Get the artifact in front of you. If the user shared a URL, fetch it. If a screenshot, look carefully. If only a description, ask one or two specific questions before guessing — designs are visual, and a vague description leads to vague feedback.

1. Identify the user's goal at this surface. Onboarding? Checkout? Re-engagement? Pricing decision? You can't review a design without knowing what success looks like.

1. Walk the four stages. For each, note which principles are in play:

• Filter: Where does the eye go? Is the hierarchy clear? Is there cognitive overload?
• Meaning: What story will the user tell themselves? Do labels/icons match their mental models?
• Action: What's the easiest path? What friction exists? What's the cost of choosing wrong?
• Memory: What will they remember tomorrow? What's the peak? The end?

1. Output a structured review. Use this shape:

• Strengths — 2-4 principles the design uses well (named, with the specific element)
• Issues — 2-5 principles being violated or missed (named, with the specific element and why it matters)
• Dark pattern flags — anything that risks crossing the line (see Dark Patterns below)
• Recommendations — concrete changes, each tied to a named principle

When generating ideas

1. Restate the problem in terms of user behavior. "How do we improve activation?" → "What makes a new user reach their first 'aha' moment faster?"
2. Pick 3-5 principles most relevant to that behavior. Use the use-case index in references/by-use-case.md.
3. For each, propose one concrete tactic. Tactic + principle + rationale. Skip principles that don't yield a concrete idea — don't pad.
4. Flag tradeoffs. Many principles have "when it backfires" notes. If a recommendation could backfire, say so.

When the user names a single principle

Just answer their question. Pull the entry from the relevant reference file, give them the definition, examples, and tips. Don't run the whole review framework.

The full index — all 106 principles

Each principle is listed with its category, a one-line summary, and the reference file where the full entry lives. Read the reference file when you need the definition, examples, "when to apply," "when it backfires," and citations for a specific principle.

🙈 Filter information (the user's brain ignores most of what you put in front of it)

Full entries: `references/01-filter-information.md`

👀 Search for meaning (users invent stories to fill gaps in what they see)

Full entries: `references/02-search-for-meaning.md`

⏰ Act within time pressure (decisions are rushed and shortcut-driven)

Full entries: `references/03-act-within-time.md`

💾 Store what mattered (memory is selective and reconstructed)

Full entries: `references/04-store-what-mattered.md`

Dark patterns: when these principles hurt users

Most of these principles are neutral tools. Some, deployed against the user's interest, become dark patterns — and reviewing for them is part of this skill's job.

The line is roughly: Is the principle being used to help the user reach their goal, or to extract from the user against their goal?

Common conversions to watch for:

When reviewing, flag these explicitly — even if the user didn't ask. A "Dark pattern flags" line in the review with zero items is a reassuring signal too.

When the user asks for ideas, prefer ethical framings. If a tactic only works as a dark pattern (confirmshaming, forced continuity), say so and suggest a non-coercive alternative that still moves the metric.

How to use the reference files

Each category file has the full entry for every principle in that category, in this shape:

## [Number]. [Principle Name]
**Category:** [Filter / Meaning / Time / Memory]
**Also known as:** [aliases if any]
**Use cases:** [pricing, onboarding, retention, …]

**Definition.** [1-2 sentences, plain English.]

**Why it works.** [The cognitive/emotional mechanism.]

**Examples in the wild.**
- [Concrete UX example with what it does and why]
- [Second example, different surface]

**When to apply.** [Specific UX situations where this is the right tool.]

**When it backfires.** [Failure modes, dark-pattern adjacency, overuse.]

**Citations.**
- [Source 1]
- [Source 2]

There's also references/by-use-case.md — a cross-index from common UX problems (pricing, onboarding, paywall, cart abandonment, retention, error states…) to the principles most relevant. Use this when generating ideas: pick the use case, look up the relevant principles, then pull their full entries.

Output style

• Name principles when you use them. "This works because of the Peak-End Rule" beats "users will remember this."
• Be concrete. "Move the testimonial above the CTA" beats "consider social proof."
• Don't list everything. A review of 15 principles is unreadable. Pick the 5-7 that matter most for this design.
• Disagree when warranted. If the user pushes a principle that's wrong for their context, say so and explain. The skill exists to be useful, not validating.
• Cite when uncertain. If you're stretching beyond what the reference files contain, say "I'm extrapolating here" and note it.

Notes on sources

This knowledge base draws from:

• growth.design — the original 106-principle framework (the structure and category approach come from here)
• Buster Benson's cognitive bias codex — the 4-stage organizing model
• Nielsen Norman Group, Interaction Design Foundation — applied UX research
• Behavioral economics literature — Kahneman, Thaler, Cialdini for the underlying mechanisms
• Wikipedia + The Decision Lab — for cross-checking definitions

Specific citations live in each principle's entry. When the literature disagrees on a definition or effect size, note the disagreement rather than picking one.