Laws Of UX

Laws of UX — Web App Design Skill

Source: lawsofux.com by Jon Yablonski · 30 evidence-based psychology laws for UX design

How This Skill Works

Mode A: Quick Question (one law, yes/no fix)

User asks: "Is this button big enough?" / "Should I add another nav item?"

1. Read Quick Reference table → find the relevant law(s)
2. Read that law's detail section only
3. Answer directly: principle + ✅/❌ verdict + one concrete suggestion
4. Skip everything else (routing, conflicts, scripts, checklist)

Mode B: Full Review / Design Session

User asks: "Review my dashboard" / "Help me design a checkout flow"

1. Understand context — what's being built? (Use Context Routing below)
2. Select 3–7 relevant laws from routing table + Quick Reference
3. Give specific feedback per law: principle → their code/UI → concrete fix → severity (🔴🟡🔵)
4. Check conflicts between selected laws → When Laws Conflict
5. Output prioritized findings list using Review Workflow
6. Stakeholder scripts (optional) — if user needs to defend decisions → Stakeholder Communication

Context Routing: What You're Building → Which Laws Matter

Forms & Input (signup, checkout, settings, search)

Common anti-pattern: Wall of 15+ fields, strict input formatting, no inline validation, identical Submit/Cancel.

Dashboards & Data-Dense Pages

Common anti-pattern: 50 metrics flat grid, no grouping, no hierarchy, everything competing.

Landing Pages & Conversion Flows

Common anti-pattern: 5 equally-weighted buttons, generic feel, no clear next step, weak end-state.

Mobile & Touch Interfaces

Common anti-pattern: Tiny tap targets crammed together, no touch feedback, desktop squished onto phone.

Navigation & Information Architecture

Common anti-pattern: 15+ top-level items, non-standard icons without labels, inconsistent hierarchy.

Quick Reference: All 30 Laws

Note: Working Memory (#17) and Miller's Law (#14) are closely related. Chunking (#16) is the primary technique for both.

The Laws (Detailed Reference)

Read on-demand after selecting relevant laws from context routing or Quick Reference. Don't present all at once.

1. Fitts's Law

Target acquisition time = f(distance, size).

Rules: Targets ≥ 44×44px (iOS) / 48×48px (Material). Never < 32px. Place primaries in easy-reach areas (top-left, center, screen edges — edges are effectively infinite). Destructive actions far from frequent ones (leverage Fitts's as safety).

Mobile thumb zones: Bottom-left/right = natural grip (green zone). Top-center = hardest reach (red zone). Put primary actions green, destructive red.

/* ✅ */ .btn { min-width: 44px; min-height: 44px; padding: 12px 24px; margin: 8px; }
/* ❌ */ .tiny { height: 20px; padding: 2px 6px; margin: 2px; }

Anti-patterns: Close buttons < 16px, dense icon toolbars without labels, dropdowns with tiny hit areas.

Validate: Track misclick rate on small targets. Heatmap tap density. If > 3% of taps miss, enlarge.

2. Doherty Threshold

Respond < 400ms or lose attention.

Rules: Visual feedback < 100ms (hover, press, focus). **Optimistic UI** — don't block on server for local actions (toggles, likes, checkboxes). Show progress for anything > 1s (spinners, skeletons, bars).

Perceived performance tricks: Skeletons > spinners. Animated progress bars feel faster even if indeterminate. Staggered reveal holds attention. Micro-delays after payment increase perceived value ("something important happened").

// ✅ Instant visual, async sync
const handleLike = () => {
  setLiked(!liked);                          // < 100ms
  mutateToggleLike(id).catch(() => setLiked(!liked)); // async
};
// ❌ Blocking await — user stares at nothing
await api.toggleLike(id); setLiked(!liked);

Anti-patterns: Unresponsive during fetches, blank route transitions, no loading states.

Validate: Time-to-interactive. Lighthouse "First Input Delay." User studies: watch for repeated clicks (sign of "did it register?").

3. Hick's Law

More choices = slower decisions.

Rules: Progressively disclose — show only what's needed now. Wizards, accordions, "Advanced ▾". Highlight default — guide don't overwhelm. Break forms into steps — 20 fields → 3 steps of ~7. Nav: ~5–7 items top level.

// ✅ Progressive disclosure
<Section title="Basic" defaultOpen><Toggle label="Notifications" /></Section>
<Collapsible title="Advanced"><Select label="Cache strategy" /></Collapsible>
// ❌ Wall of choices — 25 fields at once

Anti-patterns: 15+ nav items, every metric visible, 50-option selects, pricing with no recommended plan.

Validate: Form completion time (before/after splitting steps). Drop-off rate per added option. Heatmap dwell time on decision points.

4. Jakob's Law

Users spend most time on other sites. Yours should work like them.

Rules: Logo → home (top-left), cart → top-right, search → 🔍, mobile → hamburger, hierarchy → breadcrumbs. Don't reinvent date pickers, modals, dropdowns, tabs unless you have overwhelming reason. When innovating, provide off-ramp (YouTube redesign approach).

The innovation tradeoff: Novel patterns incur training debt. Ask: Does this give enough value to justify learning cost?

Anti-patterns: Custom scroll behavior, repositioned submit button, novel navigation without signifiers.

Validate: Task completion time for first-time users vs returning users. If first-time is dramatically slower, Jakob's debt may be too high. Onboarding drop-off rate.

5. Mental Model

Design for how users THINK it works.

Rules: Leverage existing models ("like Spotify" → Spotify metaphors). Bridge gaps with analogies. Expose cause-and-effect visibly. Avoid hidden modes (double-click ≠ single-click in same context).

Detect broken models: Users hesitate, hover aimlessly, click wrong thing repeatedly, say "I thought it would..."

Anti-patterns: Hidden features, inconsistent behaviors across similar elements, abstract icons without labels.

Validate: Think-aloud protocols. Watch for surprise ("I didn't expect that to happen"). Error patterns that suggest wrong mental model.

6. Paradox of the Active User

Nobody reads docs. They start clicking immediately.

Rules: Zero-onboarding usage possible. Defaults work well. Core value accessible without tutorial. Contextual help > documentation. Tooltips, inline hints, microcopy beat PDFs. Design error recovery. Undo, clear next steps, forgiving inputs. Learning by doing. Tours interact with real UI, progressive feature reveal.

The 10-second test: Can a new user accomplish something meaningful within 10 seconds? If not, most bounce before finding help.

Anti-patterns: Mandatory 10-step onboarding before access, features locked behind docs, errors referencing manual page numbers.

Validate: Time-to-first-value. Onboarding completion rate (if mandatory). Support ticket frequency for "how do I..." questions that should be discoverable.

7. Law of Proximity

Near items = related items.

Rules: Group with whitespace, not lines. Label closer to its input than next field's label. Consistent spacing scale (base 4px: 4, 8, 12, 16, 24, 32, 48, 64). Within-group gap < between-group gap.

/* ✅ Proximity creates groups */
.form-group { display: flex; flex-direction: column; gap: 6px; margin-bottom: 24px; }
/* ❌ Uniform spacing = no grouping */
.form-bad > * + * { margin-top: 16px; }

Where it applies: Form labels, card titles, toolbar icon groups, list items, definition lists. Bring related things closer, push unrelated apart.

8. Law of Similarity

Same look = same kind.

Rules: Same style = same type. All primary buttons match. All destructive = red. All links share color/underline. Different actions MUST look different. Cancel ≠ Submit visually.

/* ✅ Visual language = function */
.primary   { background: #0066cc; color: white; font-weight: 600; }
.secondary { background: #f0f0f0; color: #333; }
.danger    { background: #dc3545; color: white; }
/* ❌ Same look, different function = confusion */
.submit { background: #0066cc; } .cancel { background: #0066cc; }

Pro tip: Audit in grayscale. Can't distinguish action types by size/shape/weight alone? Over-relying on color = accessibility issue.

9. Law of Common Region

Shared boundary = shared group.

Rules: Cards, panels, containers = regions (background, border, shadow). Sidebar/main/header = regions via contrast. Wizard steps as cards = clear stage boundaries.

Hierarchy: Common Region > Proximity. Items in same card grouped even if spaced within it. Items in different cards seen as separate even if close.

<!-- Regions group by boundary -->
<div class="grid grid-cols-3 gap-6">
  <div class="card col-span-2"><h3>Analytics</h3></div>  <!-- region A -->
  <div class="card"><h3>Quick Actions</h3></div>           <!-- region B -->
</div>

10. Law of Uniform Connectedness

Connected elements = related.

Rules: Connector lines beat proximity. Timelines, workflows, step indicators — lines show sequence. Breadcrumb separators, table row borders exploit this.

Gestalt strength: Uniform Connectedness > Common Region > Similarity > Proximity. When in doubt, draw a line.

<!-- Step indicator uses connection -->
<div class="steps">──●──●──○</div>
<!-- List border connects items -->
<ul class="connected-list"><li>A</li><li>B</li><li>C</li></ul>

11. Law of Prägnanz (Simplicity)

Complex → interpreted as simplest form.

Rules: Every element earns its place ("Does this help the user NOW?"). Recognizable icons only (trash can = trash can). Standard layouts (single-col reading, grid browsing, sidebar+main tools). Decorative complexity without function = cognitive tax.

Simplicity test: Describe page structure in one sentence: "It's a [layout] with [main] and [secondary]." Need five sentences? Too much going on.

12. Von Restorff Effect (Isolation Effect)

Odd one out remembered best.

Rules: One standout per screen max. Primary CTA visually distinct from secondary/cancel. Important notifications break pattern. Restraint = skill. Pick 1-2 emphasis dimensions (size, weight, color, position, motion). Not all everywhere.

/* ✅ One pops */
.secondary { background: #f0f0f0; }
.primary   { background: #0066cc; color: white; font-weight: 600; } /* pops */
.danger    { background: #dc3545; color: white; } /* sparse */
/* ❌ Everything competes */
.a { background: red; } .b { background: blue; font-size: 1.2em; } .c { background: yellow; animation: pulse; }

⚠️ Accessibility: Never rely on color alone. Combine size + weight + shape + position + text. Respect prefers-reduced-motion.

⚠️ Ad-blindness risk: Standout element that looks like banner ad (flashing, aggressive contrast, ad placement) → users tune out via Selective Attention. Emphasis must feel native.

13. Selective Attention

People focus only on goal-related stimuli.

Rules: Ignore off-goal content (checkout user misses newsletter banner). Design for goal-state RIGHT NOW. Avoid banner-blindness zones (top-right banners, ad-like footers). In-context beats prominent (inline message where user looks > interrupting modal).

Goal-State Mapping technique:

Goal: "Find pricing"
→ Pricing link obvious in nav + footer + homepage
→ No "Read our blog" popup on pricing page
→ Nav clutter removed on pricing page (Hick's + Selective Attention combo)

Goal: "Submit this form"
→ Header/nav/footer/sidebar stripped — pure form view
→ Progress indicator shown (Working Memory)
→ One clear CTA (Von Restorff)
→ Inline validation, fast (Doherty + Postel's)

Anti-pattern: Promo banners on checkout, modals interrupting tasks, critical info in footers on task pages.

14. Miller's Law

Working memory holds 7±2 items.

Rules: ~5–9 items per view (nav tabs, filters, radios). Chunk to stay within limit. Never require cross-page recall. Practical limit: 4±1 for complex items (menu options with labels) — original paper was 1D stimuli; real items are richer. Err toward fewer.

Validate: Card sorting studies. Eye-tracking (fixation count per area). Task success when N items present vs reduced.

15. Cognitive Load

Mental resources needed to understand your UI.

Three types — know which you're designing for:

Golden rule: One concept per screen. Settings categorized, not 50 toggles flat.

Validate: NASA-TLX task load assessment (research method). Time-on-task comparisons. Error rate correlation with interface complexity.

16. Chunking

Break info into meaningful groups.

Rules: Group nav under headings ("Account", "Billing"). Format data for scanning (phones, dates, addresses). Card grids chunk content (12 posts → 3×4 cards). Breadcrumbs = spatial chunks.

Chunking vs Progressive Disclosure: Chunking organizes WHAT'S VISIBLE. PD controls HOW MUCH IS VISIBLE. They work together — show few chunks, expand within each.

Practical sizes: Nav group: 3-7. Form step: 4-7 fields. Dashboard row: 2-4 cards. Table cols: 4-8 visible. List before paginate: 7-15.

17. Working Memory

Temporary memory for active tasks.

Rules: Never ask users to recall from previous step without showing it ("Step 3 of 3" summarizes 1&2). Persist values (navigate away/back → draft still there). State visibility always (saving? saved? what's left?). Multi-step = persistent progress indicator.

Micro-friction cost: Every forgotten piece = tiny frustration. Accumulates → abandonment.

Implementation checklist: Auto-save drafts ✓. Summarize prior selections ✓. Save status visible ✓. Restore state on return ✓.

Validate: Return rate after abandonment (did draft-saving bring them back?). Error rate on multi-step flows (does state visibility reduce mistakes?). "Start over" click rate.

18. Serial Position Effect

First and last remembered best.

Rules: Most important item first, most important action last. Nav: most-used first. Form: primary CTA last. Pricing: recommended plan first or last (or Von Restorff-highlighted). Accept middle amnesia in equal lists.

Beyond lists: Menu: revenue links first. Announcements: lead with biggest win. Errors: most actionable first (not necessarily first from backend). Testimonials: strongest quote first or last.

19. Aesthetic-Usability Effect

Pretty = feels more usable.

Rules: Polish is functional, not cosmetic. Cohesive design system (type, color, spacing, icons). ⚠️ Beauty masks problems — test function separately from form. First impression: ~50ms. Above-the-fold sets tone for everything.

Polish checklist: Consistent type scale ✓. Harmonious colors ✓. Whitespace ✓. Single icon family ✓. Micro-interactions ✓. Responsive everywhere ✓. No ragged edges/misalignments ✓.

Stakeholder pitch: "Investing in visual quality isn't vanity — the Aesthetic-Usability Effect is well-documented. Users report higher satisfaction and tolerance in polished interfaces. It's a usability multiplier."

Validate: A/B test: same functionality, different polish levels. Perceived usability ratings (expect pretty version to score higher even if functionally identical). Task completion rates (the real test — sometimes pretty version wins, sometimes it masks problems).

20. Peak-End Rule

Judged by peak emotion + final moment.

Rules: Design peak moments at task completion (confetti, copy, animation). End every flow on high note (warm confirmation + next steps). Negative peaks linger longer — invest in error recovery. Map journey → identify peaks → design intentionally.

Flow endings ranked:

1. ✅ Delight + clear next step (confetti + "View order")
2. ✅ Warm confirmation + next step
3. ⚠️ Confirmation only ("Done") — functional, forgettable
4. ❌ Abrupt cutoff — feels broken
5. ❌ Negative peak at end — worst impression

// ✅ Strong end
<SuccessScreen>
  <Confetti />
  <Heading>Order #{id} confirmed!</Heading>
  <p>Email sent to {email} with tracking.</p>
  <CTA href="/orders">View Details</CTA>
</SuccessScreen>
// ❌ Dead end
<div>Thank you. Order received.</div>

Validate: NPS/CSAT measured at flow endpoints (Peak-End prediction: these scores weight heavily on final moment). Exit survey after key flows. Return rate post-completion (did good ending bring them back?).

21. Zeigarnik Effect

Incomplete tasks remembered better.

Rules: Show incomplete progress prominently ("75% complete", "3 of 8 remaining"). Partial progress motivates (endowed progress: signup instant 10%). Auto-save drafts → incomplete = return motivation. Never hide in-progress state (drafts, abandoned carts, unfinished points).

<Card>
  <ProgressBar value={percent} />
  <p>{percent}% complete</p>
  {percent < 100 && <Link to="/settings/profile">Complete →</Link>}
</Card>

⚠️ Ethics: Powerful but can manipulate (gamification dark patterns, artificial urgency). Use for genuinely valuable tasks, not addictive looping.

Validate: Return/abandonment rate after showing progress bar (before/after). Profile completion rate with vs without endowed progress. Draft recovery rate (auto-saved drafts reopened within 7 days).

22. Goal-Gradient Effect

Closer to goal = more motivated.

Rules: Accelerate perceived progress near end (smaller remaining steps, larger increments). Framing: "Only 2 purchases until Gold!" >> "10 to reach Gold." Large goals → milestones. Onboarding bars filling faster near end = higher finish rates.

Techniques: Non-linear easing progress bar (accelerates toward 100%). Milestone celebrations at 25/50/75%. "Almost there!" when >80%. Remaining count near goal ("2 steps left" > "92%").

Validate: Funnel progression velocity (do users speed up near end?). Milestone engagement rate (do 25/50/75% markers increase activity?). A/B: linear vs accelerated progress bar.

23. Flow

Immersed focus state.

Rules: Match challenge to skill (novices → guided, experts → shortcuts/bulk). Remove friction from core tasks (writing app → distraction-free, IDE → seamless code/run/debug). Immediate feedback loops (Doherty). Don't interrupt flow with modals/upsells during focus tasks.

Broken flow signs: User stops to think "where next?", waits, switches context, gets pulled away. Each break risks losing flow — takes 15-25 minutes to regain deep flow.

Flow-friendly patterns: Keyboard shortcuts. Command palette (Cmd+K). Auto-save. Distraction-free/fullscreen mode. Batch operations (select many → act once).

Validate: Session duration for focus tasks (longer = more flow). Interruption recovery time. Power-user feature adoption rate. Keyboard shortcut usage analytics.

24. Cognitive Bias

Systematic thinking errors.

Ethical persuasion toolkit:

• Anchoring: Original price crossed out next to sale
• Social proof: "10,000+ developers" (must be genuine)
• Scarcity (genuine only): "3 spots left"
• Defaults: Pre-select recommended option
• Authority: "Recommended by [trusted expert]"

Dark patterns to never use: Fake scarcity. Forced continuity (auto-bill without warning). Confirmshaming ("No, I want to miss out"). Roach motel (easy join, impossible leave). Hidden costs at checkout.

Trust equation: Short-term dark pattern gains << Long-term trust value. Every deceptive manipulation erodes future trust.

Validate: Conversion rates with ethical vs dark patterns (dark usually wins short-term, loses long-term). Churn rate post-signup (did manipulative signup backfire?). Support ticket sentiment analysis.

25. Choice Overload (Paradox of Choice)

Too many options = paralysis.

Rules: Curate 3-5 options. "See all" for power users. Smart recommendations / "Pick for me." Categorized choice architecture (50 in 5 categories of 10 >> 50 flat). Defer complex decisions (favorite, compare, "decide later").

Sweet spot: Research shows 3-5 options maximizes satisfaction. <3 feels constraining. >7 causes measurable fatigue. 3-5 with recommended default = optimal.

Many-options fallback: Default pre-selected → filters to narrow → comparison mode → "decide later" with save.

Validate: Decision completion rate vs number of options presented (graph it — expect inverted-U curve). Time-to-decision. "Skip" / abandon rate at selection screens.

26. Tesler's Law (Conservation of Complexity)

Complexity can't die. Only move — code or user's brain.

Rules: Absorb complexity in code, not UI. Smart defaults (10 settings? Pick good ones, let users override). Don't oversimplify to abstraction ("Auto" that doesn't work well >> thoughtful controls). Simple surface, advanced underneath. Progressive disclosure = answer.

// ✅ System absorbs complexity
<SmartDateInput label="When?" /* parses, timezone, validates, formats */ />
// ❌ Complexity dumped on user
<input placeholder="2024-01-15T14:30:00+00:00" label="Enter ISO 8601 with timezone..." />

Engineer's tradeoff: 1 extra week reducing UI complexity saves millions × 1 minute each. Always absorb in code.

Signs complexity is misplaced: Users need docs for basic features. Errors expose internals (UUIDs, stack traces). "Why is this so complicated?" about common tasks.

Validate: Time-to-task-completion before/after simplification. Support ticket complexity ("how do I..."). Feature discovery rate (are advanced features being used or ignored?).

27. Postel's Law (Robustness Principle)

Liberal in what you accept, conservative in what you send.

Rules: Accept varied input gracefully — phones (555) 123-4567 / 555.123.4567 / 5551234567, names with unicode/spaces/hyphens, dates in any format, search with typos/fuzzy match. Output clean normalized data. Forgive errors ("Did you mean...?" > "Invalid."). Graceful degradation.

// ✅ Liberal input, conservative output
<input => {
  const raw = e.target.value.replace(/[^\d+\-\s().]/g, '');
  onChange(raw); // normalize internally
}} placeholder="(555) 123-4567" />
// Output: phone.replace(/\D/g, '') → "+1 (555) 123-4567" → "15551234567"

Foundation of forgiving UX. Combine with Doherty (fast validation) + Active User (no manual needed) = forms that feel intelligent, not rigid.

Validate: Form error rate by input format diversity. Support tickets for "it won't accept my [valid] input." Completion rate with forgiving vs strict validation.

28. Occam's Razor

Simplest solution with fewest assumptions wins.

Rules: Simplest explanation for behavior is usually right (button not clicked? Doesn't look clickable / poorly positioned / unclear label — NOT "users don't understand our paradigm"). Fewer moving parts wins. Not every screen needs A/B testing, animation, or real-time validation.

Occam's questions before adding anything:

1. Does this solve a real observed problem?
2. Is there a simpler way?
3. Does this add a new user concept?
4. Would removing it break anything?
5. Can we ship without it and add later?

The trap: "Simplest" ≠ "oversimplified to useless." Simplest that actually solves the problem. Under-simplifying = Tesler's violation (complexity pushed to user).

Validate: Feature usage rate (is the complex version actually used?). Support tickets for confused users. A/B: simple vs full-featured version.

29. Parkinson's Law

Work expands to fill available time.

Rules: Design for speed (auto-save, shortcuts, templates, bulk ops). Implicit deadlines (progress bars, "Step 2 of 4", ETA). Remove unnecessary steps. Pre-fill everything possible.

Parkinson's manifests as: Forms: could be 3 fields but are 10 (space existed). Onboarding: 5 minutes because nobody constrained it. Checkout: 6 steps (each team added "just one more"). Settings: grew organically without pruning.

Counter-tactics: Arbitrary constraints at design time ("fits one screen," "checkout ≤ 3 steps"). Time yourself (you built it = 2min → user takes 10+). Measure drop-off per step (abandonment = bloat signal).

Validate: Time-on-task measurements. Step-by-step funnel drop-off (which step loses most users?). Form completion time with vs without pre-fill. Before/after constraint-imposed redesign.

Combined Application: How Laws Work Together

Real design never applies one law in isolation. Here's how they combine on common components:

A Well-Designed Card Component

┌─────────────────────────────────┐  ← Common Region (boundary groups content)
│ 📊 Revenue        $12,400      │  ← Similarity (icon + label + value pattern)
│                         ↑ +8%   │  ← Von Restorff (trend badge pops — ONE emphasis)
│                                 │
│ ─────── ─────── ───────       │  ← Uniform Connectedness (lines = related)
│ Jan    Feb    Mar            │     sub-items
└─────────────────────────────────┘  ← Prägnanz (simple layout, scannable)
     ↑                           ← Proximity (title close to chart, far from next card)

Laws applied: Common Region + Similarity + Von Restorff + Uniform Connectedness + Prägnanz + Proximity = 6 laws on one component. This is normal.

A Multi-Step Signup Form

Step 1: Create Account    ●━━━━●━━━━○━━━━○   ← Uniform Connectedness (progress)
                        ↑                ← Doherty (inline validation < 400ms)
  Email: [____________]                  ← Postel's (accepts any email format)
  Password: [__________]                 ← Tesler's (password strength meter;
                                         shows requirements inline)

Step 2: Your Profile                     ← Hick's (only 3 fields — not 10)
  Name: [_____________]                 ← Fitts's (44px inputs, spaced 8px apart)
  Avatar: [Upload]                      ← Von Restorff (primary "Upload" button pops)

Step 3: Preferences  (collapsed ▾)      ← Progressive disclosure (Hick's again)
  [✓] Email updates                    ← Default pre-selected (Cognitive Bias)
  [  ] SMS notifications               ← Zeigarnik (overall progress: 66%)
                                       ← Working Memory (steps 1-2 summarized here)

Laws applied: 9 laws working together across 3 steps. This is what real design looks like.

A Dashboard Page

┌─ Navigation ──────────────┐  ← Jakob's (conventional left-nav)
│ Home  Analytics  Settings  │     Hick's (5 items, grouped)
│                            │
├──────────────┬─────────────┤  ← Proximity (two regions, loosely spaced)
│             │             │
│  ANALYTICS  │  QUICK ACTS  │  ← Common Region (cards = regions)
│  ┌─────┐    │  ┌─────┐    │
│  │ Rev │    │  │ +Add│    │  ← Similarity (same card structure)
│  │Users│    │  │Export│   │
│  └─────┘    │  └─────┘    │
│  ┌─────┐    │             │
│  │Bounce│   │             │  ← Von Restorff (alert card pops if error)
│  └─────┘    │             │
└──────────────┴─────────────┘  ← Prägnanz (whole thing describable in one sentence)
   ↑ Cognitive Load: one concept per region
   ↑ Selective Attention: highest metrics in scan path (top-left of main)
   ↑ Serial Position: most important metric first (Revenue)

Takeaway: Don't try to apply laws one-at-a-time. Design the component, then audit against relevant laws to find gaps.

Real-World Teardowns

Teardown 1: GitHub Settings Page (Before → After)

Before (typical SaaS anti-pattern):

• 50+ toggles in a flat alphabetical list
• No grouping, no search, no indication of which settings matter
• "Advanced" toggle mixed with basic preferences
• Each toggle identical visual weight
• No way to understand impact of changing a setting

Laws violated: Cognitive Load (🔴), Hick's Law (🔴), Chunking (🔁), Von Restorff (none — nothing stands out), Miller's Law (🔴), Tesler's Law (complexity dumped on user)

After (applying laws):

• Chunked into 4 categories: Account, Notifications, Integrations, Advanced (Chunking + Cognitive Load)
• Search bar at top (Postel's — accepts fuzzy queries)
• Each category collapsed by default (Hick's — progressive disclosure)
• "Danger Zone" for destructive actions in separate red-bordered card (Von Restorff + Common Region + Fitts's — dangerous actions far from frequent ones)
• Most-common settings have smart defaults pre-selected (Tesler's + Cognitive Bias)
• "Reset to defaults" button at bottom (Paradox of Active User — recovery from bad changes)

Result: Settings went from overwhelming to navigable in one redesign pass.

Teardown 2: Typical SaaS Pricing Page (Before → After)

Before:

• 3 pricing tiers in identically styled cards
• No recommendation (user must figure out which plan)
• All features listed for all plans (decision fatigue)
• CTA buttons identical weight/color
• No urgency or social proof

Laws violated: Von Restorff (🔴 — no standout), Choice Overload (🔴), Hick's Law (🔴), Cognitive Bias (missing — no anchoring/social proof/defaults), Peak-End Rule (weak end state)

After:

• Middle plan (recommended) has highlighted border + "Most Popular" badge (Von Restorff — one pops)
• Left plan crossed-out original price next to current (Cognitive Bias — anchoring)
• "Basic / Pro / Enterprise" → "For individuals / For teams / For companies" (chunking by user type, not feature count)
• Only 3-5 differences between plans shown (others collapsed under "Everything in Basic plus...") (Hick's — reduced comparison scope)
• Primary CTA larger + colored, secondary "Contact Sales" muted (Von Restorff + Fitts's)
• "Join 10,000+ teams" below CTA (Social proof — genuine)
• After clicking CTA: warm confirmation with setup timeline (Peak-End Rule)

Result: Conversion typically increases 15-30% with these changes (based on aggregated case studies from nngroup.com, conversionciencia.com).

Teardown 3: E-commerce Checkout Flow (Before → After)

Before:

• All 15 fields on one page
• Strict date/phone formatting (errors if user types "naturally")
• No progress indicator
• Generic "Order confirmed" text at end
• Error messages: "Invalid input" (no guidance)
• Loading spinner on submit, no feedback during wait

Laws violated: Postel's (🔴), Hick's (🔴), Doherty (🔴), Working Memory (🟡), Peak-End Rule (🔴), Fitts's (🟡)

After:

• 3 steps: Cart → Shipping/Payment → Confirm (Hick's + Miller's)
• Phone field accepts any format, displays formatted (Postel's)
• Inline validation on blur (Doherty < 400ms)
• Optimistic "Processing..." with confetti animation (Doherty perceived perf + Peak-End delight)
• "Step 2 of 3" header summarizes cart contents (Working Memory)
• Large 44px touch targets throughout (Fitts's)
• Final screen: order summary + tracking link + "You might also like" (Peak-End strong finish + Goal-Gradient)

Result: Cart abandonment typically drops 20-35% with optimized checkout flows (Baymard Institute benchmark data).

When Laws Conflict

Fitts's vs Von Restorff

Tension: Everything big (Fitts's) vs one thing pops (Von Restorff) Resolution: All elements meet 44px minimum (Fitts's floor). Use weight/color/position for primary CTA only (Von Restorff ceiling). Every button reachable; only one demands attention.

Hick's vs Postel's

Tension: Limit choices (Hick's) vs accept any input (Postel's) Resolution: Present few focused options in UI (dropdown, presets) but accept flexible text input as fallback. Date picker shows calendar (few choices) + accepts typed dates in any format (liberal input).

Jakob's vs Innovation

Tension: Conventional (Jakob's) vs differentiate Resolution: Conventional in interaction (works as expected) + distinctive in personality (visual brand, voice, micro-interactions). Innovation reserved for where convention is genuinely broken.

Aesthetic-Usability vs Peak-End

Tension: Polish everywhere (AE) vs peaks/ends only (Peak-End) Resolution: AE sets baseline quality (every screen meets bar). Peak-End identifies 2-3 moments for extra investment (onboarding complete, first success, checkout confirm). Budget: 80% consistent quality, 20% peak delight.

Tesler's vs Occam's

Tension: Absorb complexity (Tesler's) vs keep simple (Occam's) Resolution: Allies, not enemies. Occam's = WHAT to build (simplest solution that works). Tesler's = WHERE complexity lives (code, not UI). Simple UI often needs sophisticated code (smart defaults, fuzzy parsing).

Von Restorff vs Accessibility

Tension: Stand out (Von Restorff) vs don't rely on color (a11y) Resolution: Multi-dimensional emphasis. Size + weight + position + color (not color alone). Primary button bigger, bolder, positioned prominently, AND colored differently. Win-win.

Cognitive Bias vs Trust

Tension: Guide choices (Bias) vs don't manipulate (Trust) Resolution: Line = transparency. Anchoring/social proof/defaults ethical when: claims genuine, user benefits, can opt out easily. Unethical when: fabricated claims, self-serving guidance, hidden opt-out.

Review Workflow

Run this protocol when reviewing any UI. Output: prioritized findings list.

Phase 1: Gather

1. Screenshot/screen the interface being reviewed
2. Identify user's goal-state (what are they trying to accomplish here?)
3. Note the context (desktop/mobile? first-time user? power user?

…(truncated)