---
name: jpoindexter/laws-of-ux-and-psychology
source: https://app.decimal.ai/s/jpoindexter-laws-of-ux-and-psychology@1/SKILL.md
source_sha256: 5ce976908075
---

# Laws of UX & Cognitive Principles

These are not style opinions. Each "law" is a named finding from perceptual psychology, cognitive science, or behavioral economics that constrains how *every* human uses *every* screen — desktop, mobile, watch, voice, kiosk. Jon Yablonski's *Laws of UX* (lawsofux.com, 2020) collected the design-facing subset; the originals trace to the researchers credited below. Cite the source when you invoke a law in a design review — "this fails Fitts" lands harder than "the button feels small."

Read each law as a fixed five-part block: **Origin** (who/when), **Principle** (the mechanism, with the math where it exists), **In the UI** (one concrete control or screen), **Implication** (the general rule you derive), **Pitfall** (the failure mode). Keep "In the UI" and "Implication" distinct: the first is an example, the second is the rule.

The laws also *combine* — most good interactions satisfy several at once and most bad ones violate a cluster. A fast, optimistic submit serves Doherty *and* Flow; a forgiving, system-parsed input field serves Postel *and* Tesler *and* Recognition-over-recall. When two laws appear to conflict (Hick says fewer choices, but Jakob says match the conventional five-tab bar users expect), Jakob usually wins for plumbing and Hick for content — convention is a learned default that costs nothing, novelty is the expensive part.

---

## 1. Targeting & decision laws (the geometric ones)

### Fitts's Law
- **Origin:** Paul Fitts, 1954. Formalized in *The information capacity of the human motor system*.
- **Principle:** Time to acquire a target = `T ≈ a + b·log₂(2D/W)`, where `D` = distance to target, `W` = target width along the motion axis. Acquisition time grows *logarithmically* with distance and *shrinks* as the target gets bigger. Doubling size helps far more than the formula's modest log on distance suggests in dense UIs.
- **In the UI:** A primary CTA rendered 48px tall and placed near the user's current focus is hit fast; the same action as a 16px text link in a far corner is slow and error-prone. Screen *edges and corners* have effectively infinite width (the pointer stops dead) — macOS menu bar, Windows Start corner, the right-click context menu spawned *at* the cursor (`D≈0`).
- **Implication:** Make important, frequent targets big and near. Anchor destructive or rare targets far and small. Exploit edges, corners, and the pointer's own position for the loudest actions.
- **Pitfall:** Tiny icon-only buttons crammed together (toolbar of 24px glyphs at 4px gaps) — every click is a coin-flip. Also: a big *visual* button with a small *hit area* (padding outside the clickable region) silently breaks the law.

### Hick's Law (Hick-Hyman Law)
- **Origin:** William Edmund Hick **and** Ray Hyman, 1952 — independent papers, jointly named. Don't drop Hyman.
- **Principle:** Decision time rises logarithmically with the number of equally-probable choices: `RT = b·log₂(n + 1)`. Each doubling of options adds a roughly constant slice of deliberation, not a linear pile.
- **In the UI:** A checkout with one obvious "Pay" button decides instantly; a settings page dumping 40 toggles at once stalls the user. Chunking the 40 into 6 labeled groups, or revealing advanced options behind a disclosure, restores speed.
- **Implication:** Reduce or *categorize* choices. Use progressive disclosure, smart defaults (a pre-selected sensible option removes the decision entirely), and grouping. Highlight a recommended path so the user can skip the comparison.
- **Pitfall:** Over-applying it into death-by-wizard — splitting one coherent choice across ten one-question screens adds navigation cost and hides context. Hick's targets *count and grouping*, not "fewer screens always."

---

## 2. Memory & cognition laws

### Miller's Law
- **Origin:** George A. Miller, 1956, *The Magical Number Seven, Plus or Minus Two*.
- **Principle:** Working memory holds ~7±2 **chunks**, not items. The number is about *units of meaning*, and a chunk can be large (a familiar acronym, a grouped phone segment). **Nuance/myth:** "7" is widely misquoted as a hard cap on menu items or nav links — it is not. Cowan's later work (2001) refines the real span to ~4 chunks. The usable lesson is *chunk and group*, not "never exceed seven."
- **In the UI:** A phone number shown as `+1 (415) 555-0132` is four chunks and trivially held; `+14155550132` is twelve digits and slips. Card numbers grouped in 4s, OTP fields in segments, nav grouped into labeled sections.
- **Implication:** Format and group information into meaningful chunks so the user holds a structure, not a stream. Don't make the user keep facts in their head across steps — show them on screen (recognition over recall, §5).
- **Pitfall:** Citing "7±2" to justify capping a menu at seven links, or worse, padding to seven. Navigation breadth is governed by scanability and labeling, not this number.

### Jakob's Law
- **Origin:** Jakob Nielsen, 2000.
- **Principle:** Users spend most of their time on *other* sites and apps. They form mental models from the aggregate, and they expect *yours* to work the same way. Familiarity is transferred expectation.
- **In the UI:** A logo top-left links home; a magnifying glass means search; a cart icon top-right holds purchases; underlined blue-ish text is a link. Users "know" your product before they see it because they've used a thousand like it.
- **Implication:** Honor conventions for anything the user didn't come to admire — navigation, controls, icons, gestures. Innovate on your *core value*, not on where the back button lives. When you must break a convention, make the new pattern obvious and cheap to learn.
- **Pitfall:** "Reimagining" the scrollbar, hijacking the back gesture, or inventing a novel hamburger-replacement to look fresh. Novelty in plumbing is a tax the user pays on every visit.

### Von Restorff Effect (Isolation Effect)
- **Origin:** Hedwig von Restorff, 1933.
- **Principle:** When multiple similar objects are present, the one that *differs* is the most likely to be noticed and remembered.
- **In the UI:** On a row of grey secondary buttons, one filled accent "Continue" owns attention. A pricing table's "Most popular" tier lifted, bordered, and badged is the one people recall and pick.
- **Implication:** Make the single most important element visually distinct — and *only* it. Distinctiveness is a scarce resource spent on one focal point.
- **Pitfall:** Emphasizing everything (three "primary" buttons, five highlighted plans) — when all stand out, none does. Beware relying on color alone for the distinction (fails for colorblind users; pair with shape/weight/label).

### Serial Position Effect
- **Origin:** Hermann Ebbinghaus (memory curve work, 1880s–1900s); primacy/recency formalized in the serial-position literature thereafter.
- **Principle:** Items at the **start** (primacy) and **end** (recency) of a series are recalled best; the middle sags.
- **In the UI:** Put the most important nav items first and last in a top bar; the throwaway middle holds lower-stakes links. The last step of a flow and the first impression carry disproportionate memory weight.
- **Implication:** Anchor high-value items to the ends of any sequence — nav, lists, onboarding steps, menus. Don't bury the key action in the middle of a long list.
- **Pitfall:** Alphabetical or arbitrary ordering of a critical menu, dropping your most-used action into position 6 of 11 where it's least remembered and least scanned.

---

## 3. Complexity & robustness laws (system-side)

### Tesler's Law (Conservation of Complexity)
- **Origin:** Larry Tesler, Xerox PARC, early 1980s.
- **Principle:** Every application has an irreducible amount of inherent complexity. The only question is **who absorbs it** — the system/engineer, or the user. It cannot be deleted, only relocated.
- **In the UI:** An email "To:" field that accepts a raw address, a pasted name, *or* a contact pick — the app does the parsing so the user doesn't format anything. Date pickers that read "next friday." Shipping forms that derive city/state from a ZIP.
- **Implication:** Push complexity *into the system*. Do the parsing, the inference, the defaulting, the validation server-side so the user's surface stays simple. Engineering effort is the right place for the cost to land.
- **Pitfall:** "Just make the user enter it in the exact format" — exporting your parsing complexity onto every user, every time. Equally wrong: hiding *necessary* complexity so far that power users can't reach it.

### Postel's Law (Robustness Principle)
- **Origin:** Jon Postel, 1980, RFC 760/761 (and 793): "be conservative in what you send, liberal in what you accept."
- **Principle:** Be liberal in what you *accept* as input, conservative in what you *emit*. Tolerate variation at the boundary; produce clean, predictable output.
- **In the UI:** A phone field that accepts `415-555-0132`, `(415) 555 0132`, or `4155550132` and normalizes on submit. Search that forgives typos. Forms that trim whitespace and case-fold emails silently.
- **Implication:** Forgive the user's input format; never reject for cosmetics you could clean yourself. Reserve hard validation for genuine ambiguity, and explain it precisely when you must.
- **Pitfall:** Over-liberalism that swallows real errors (accepting a malformed email so the user never gets the receipt). Robustness means *forgive formatting*, not *accept garbage*.

---

## 4. Time, motivation & memory-of-experience laws

### Doherty Threshold
- **Origin:** Walter J. Doherty **and** Arvind J. Thadani, IBM, 1982.
- **Principle:** When system response drops below **400ms**, the human and machine enter a tight feedback loop and *productivity jumps* — users stay in flow and even do more than asked. Above ~400ms, attention drifts and the experience feels like waiting.
- **In the UI:** Keep interactions under 400ms. Where the real work is slower, fake the speed: **optimistic UI** (show the liked state instantly, reconcile later), **skeleton screens** instead of spinners, instant input echo, prefetch on hover/intent.
- **Implication:** Treat perceived performance as a first-class feature. Respond to *every* input within 100ms even if only to acknowledge; complete or progress-indicate within 400ms wherever possible.
- **Pitfall:** Blocking the UI on a network round-trip with a bare spinner, or animating a transition so long (600ms+) it re-introduces the wait you optimized away. Eye-candy that costs latency is a regression.

### Goal-Gradient Effect
- **Origin:** Clark Hull, 1932 (animal-learning studies). Applied to consumers as **endowed progress** by Kivetz, Urminsky & Zheng, 2006.
- **Principle:** Motivation to reach a goal *increases* the closer one is to it. The "endowed progress" refinement: artificial early progress (a punch card pre-stamped twice) accelerates completion versus an empty start.
- **In the UI:** Progress bars and steppers that fill as the user advances. A profile-completion meter at "60%" pulls people to 100%. Onboarding that pre-checks the steps they've already done so they start "ahead."
- **Implication:** Show progress, and front-load a sense of advancement. Break long flows into a visible track so each step feels like nearing the finish.
- **Pitfall:** A progress bar that lies or resets (jumping back, an extra surprise step after "100%") destroys trust — the gradient pulls them in, the lie throws them out.

### Zeigarnik Effect
- **Origin:** Bluma Zeigarnik, 1927.
- **Principle:** People remember *incomplete* or interrupted tasks better than completed ones — open loops nag at working memory.
- **In the UI:** A "3 of 5 steps complete" onboarding checklist, a half-filled profile prompt, an empty cart badge — each open loop draws the user back. Inbox unread counts exploit it (sometimes abusively).
- **Implication:** Use visible incompleteness to motivate return and continuation — checklists, setup progress, saved drafts. Make the open loop closable in one obvious action.
- **Pitfall:** Manufacturing endless open loops (permanent badges, never-finishable checklists) breeds anxiety and notification fatigue. The effect is a nudge, not a leash.

### Peak–End Rule
- **Origin:** Daniel Kahneman and colleagues, ~1993 (Redelmeier & Kahneman colonoscopy study; Fredrickson & Kahneman).
- **Principle:** People judge an experience largely by its most intense moment (the **peak**, good or bad) and its **end** — not by the sum or average of every moment.
- **In the UI:** Invest in the high points (a delightful first success, a celebratory "shipped!" moment) and the endings (the post-purchase confirmation, the empty state after completing a task). A graceful, well-recovered error can become a positive peak.
- **Implication:** Map the journey's peaks and its ending, and design those deliberately. A smooth average with a frustrating finish is remembered as frustrating.
- **Pitfall:** Polishing the mid-funnel while the *end* is an abrupt blank page or a dead-end error. Optimizing the average and neglecting the two moments that actually get encoded.

### Aesthetic–Usability Effect
- **Origin:** Masaaki Kurosu and Kaori Kashimura, Hitachi, 1995 (ATM-layout study).
- **Principle:** Users *perceive* more aesthetically pleasing designs as more usable — and are more tolerant of minor usability problems in them.
- **In the UI:** A clean, well-typeset, harmonious interface earns trust and patience; users forgive small frictions and rate it easier even when task-time is identical to an ugly one.
- **Implication:** Visual quality is functional — it buys credibility, trust, and forgiveness. Don't dismiss polish as "just cosmetics"; it changes measured perception.
- **Pitfall (the risk):** Beauty *masks* real usability problems — in testing, a pretty prototype hides flaws users would report in a plain one. Test with realistic visuals *and* probe for issues the gloss is hiding; never let aesthetics substitute for actual task success.

---

## 5. Cognitive load, attention & focus

### Cognitive Load Theory
- **Origin:** John Sweller, 1988.
- **Principle:** Working memory has limited capacity, split three ways: **intrinsic** (inherent difficulty of the task), **extraneous** (load added by *how* it's presented — clutter, jargon, bad layout), and **germane** (effort that builds useful understanding). You can't lower intrinsic load, but you must minimize extraneous to leave room for the task.
- **In the UI:** Strip extraneous load: remove decorative noise, reduce field count, use plain labels, chunk content, defer non-essential controls. Reserve the user's capacity for the actual decision.
- **Implication:** Audit every screen for extraneous load and cut it. Match information density to the task's intrinsic difficulty; add scaffolding (germane) only where it genuinely aids learning.
- **Pitfall:** Confusing "minimal" with "low-load" — hiding essential controls *raises* load (now the user hunts). Load is about clarity and chunking, not pixel-emptiness.

### Selective Attention / Inattentional Blindness (Banner Blindness)
- **Origin:** Inattentional blindness — Simons & Chabris, 1999 ("invisible gorilla"). **Banner blindness** — Benway & Lane, 1998.
- **Principle:** Attention is selective; users focused on a goal literally do not see elements they've learned to ignore — especially ad-shaped, banner-shaped, or peripheral content.
- **In the UI:** A genuine call-to-action styled like an ad banner (top, full-width, colorful, off to the side) gets skipped. Important messages dressed as marketing are invisible to task-focused users.
- **Implication:** Place critical information *in the path of the task*, in the content column, not in banner/sidebar real estate. Don't make essential UI look like advertising.
- **Pitfall:** Sticking a key notice in a top banner or right rail and assuming it was seen. If it looks like an ad, it's gone.

### Flow
- **Origin:** Mihály Csíkszentmihályi, 1975.
- **Principle:** A state of full, energized focus reached when challenge and skill are balanced, goals are clear, and feedback is immediate. Interruptions and latency break it.
- **In the UI:** Keep responses fast (ties to Doherty), feedback immediate, the next step clear, and modal interruptions rare. Power-user shortcuts let skill rise with challenge.
- **Implication:** Protect flow — minimize disruptive dialogs, defer non-urgent notifications, keep the path forward obvious, and give instant feedback on every action.
- **Pitfall:** Interrupting deep work with cookie banners, upsell modals, or "rate us" prompts mid-task — each one ejects the user from flow and resets their context.

### Recognition over Recall
- **Origin:** Long-standing memory psychology; codified for UI in Nielsen's heuristic "Recognition rather than recall" (1994). See the `usability-heuristics` skill for the full heuristic set.
- **Principle:** Recognizing something shown is far cheaper than recalling it unaided. Visible options beat memorized commands.
- **In the UI:** Dropdowns and pickers over "type the exact code"; recently-used and autocomplete over blank fields; visible breadcrumbs over remembering where you are.
- **Implication:** Show options and context; don't force the user to hold information across screens or remember syntax. Make actions and state *visible*.
- **Pitfall:** Command-line-style UIs for novice tasks, or forms that reference a value the user saw two screens ago and must now retype from memory.

---

## 6. Productivity, scope & behavioral-economics cluster

These shape product and UX decisions; cited compactly because each is a single sharp idea.

| Law / Principle | Origin | The idea | Use it for | Pitfall |
|---|---|---|---|---|
| **Parkinson's Law** | C. Northcote Parkinson, 1955 | Work expands to fill the time allotted. | Imposed deadlines/timers focus effort (booking holds, "offer ends in 10:00"). | Manufactured fake urgency erodes trust; real scarcity only. |
| **Pareto (80/20)** | Vilfredo Pareto; named by Joseph Juran | ~80% of effects come from ~20% of causes. | Prioritize the 20% of features that drive 80% of use; optimize hot paths first. | Treating it as exact law; neglecting the long-tail 20% that retains power users. |
| **Occam's Razor** | William of Ockham (14th c.) | Among competing solutions, prefer the one with fewest assumptions. | Cut redundant steps, fields, options; simplest flow that works. | Over-simplifying past the task's irreducible complexity (see Tesler). |
| **Loss Aversion** | Kahneman & Tversky, prospect theory, 1979 | Losses loom ~2× larger than equivalent gains. | "Don't lose your progress," abandoned-cart, free-trial framing. | Dark-pattern coercion ("you'll lose everything!") to trap users. |
| **Anchoring** | Tversky & Kahneman, 1974 | First number/option seen biases all later judgments. | Show a higher "was" price, place the target plan beside a premium one. | Deceptive anchors (fake original prices) are manipulative and often illegal. |
| **Choice Overload** | Iyengar & Lepper, 2000 (jam study) | Too many options reduces likelihood of *any* choice and satisfaction with it. | Curate, recommend a default, limit visible plans/SKUs. | Confusing with Hick's (that's *speed*; this is *paralysis & regret*). |

The distinction between **Hick's Law** and **Choice Overload** is worth holding precisely, because they look identical on a cluttered screen but prescribe differently. Hick is about *deliberation time* — it scales with how many options you make a person *evaluate*, and the fix is reducing or grouping so the relevant set is small. Choice overload is about *paralysis and post-decision regret* — beyond a threshold of roughly a dozen comparable options, people defer choosing entirely or feel worse about whatever they picked, and the fix is curation plus a recommended default that lets them opt out of comparing. A plan-picker with 4 tiers is a Hick problem (speed it up); a marketplace with 200 near-identical SKUs is a choice-overload problem (curate and recommend).

> **Loss aversion / anchoring / choice overload are powerful and dual-use.** They describe real biases — use them to *help* users decide (clear defaults, honest comparison), never to coerce. Manufactured scarcity, fake anchors, and confirmshaming are dark patterns; they win the click and lose the trust.

---

## 7. Gestalt grouping (brief — see `layout-and-composition`)

The Gestalt principles (Wertheimer, Koffka, Köhler, 1920s; **Common Region** and **Uniform Connectedness** added later by Palmer & Rock) describe how the eye groups before it reads:

- **Proximity** — elements placed close together are perceived as one group. Spacing *is* grouping.
- **Common Region** — elements inside a shared boundary (a card, a panel) read as a set, even if far apart.
- **Uniform Connectedness** — elements joined by a line or shared background read as connected — the strongest grouping cue.

In practice: control grouping with *whitespace and containers*, not dividers. A form field and its label belong to the same region; a save button belongs near what it saves. The full Gestalt treatment — similarity, closure, continuity, figure/ground — lives in the **`layout-and-composition`** skill; don't re-derive it here.

---

## 8. Do / Don't

| Do | Don't |
|---|---|
| Make frequent, important targets big and near; use edges/corners (Fitts). | Cram tiny icon buttons at small gaps, or give a big button a small hit area. |
| Reduce and group choices; offer a sensible default (Hick). | Dump 40 ungrouped options, or fragment one choice into 10 screens. |
| Chunk data into meaningful units (Miller). | Cite "7±2" to cap menu items. |
| Honor platform conventions for plumbing (Jakob). | Reinvent the scrollbar, back gesture, or nav to "look fresh." |
| Push complexity into the system (Tesler); forgive input formats (Postel). | Demand exact formats; or accept genuinely broken input. |
| Respond <400ms; use optimistic UI + skeletons (Doherty). | Block on a spinner, or add a 600ms transition that re-adds the wait. |
| Design the peaks and the *ending* deliberately (Peak-End). | Polish the average and leave an abrupt blank/error finish. |
| Use polish to earn trust (Aesthetic-Usability)… | …but let beauty mask flaws or skip usability testing. |
| Emphasize one focal point (Von Restorff). | Make three things "primary" — emphasis on all = emphasis on none. |
| Show progress; front-load it (Goal-Gradient, Zeigarnik). | Reset a progress bar or invent endless open loops. |
| Put critical info in the task path (Selective Attention). | Style essential UI like an ad banner. |
| Use biases to help users decide (anchoring, defaults). | Weaponize them — fake scarcity, fake anchors, confirmshaming. |

---

## 9. Summary table (law → use it for → pitfall)

| Law | Attribution | Use it for | Pitfall |
|---|---|---|---|
| Fitts's | Fitts, 1954 | Size/place targets; exploit edges & corners | Tiny clustered buttons; visual ≠ hit area |
| Hick-Hyman | Hick & Hyman, 1952 | Cut/group choices; defaults | Death-by-wizard; over-fragmenting |
| Miller's | Miller, 1956 | Chunk & format data | "7±2" as a hard menu cap |
| Jakob's | Nielsen, 2000 | Honor conventions | Reinventing plumbing |
| Tesler's | Tesler, ~1980s | Shift complexity to system | Exporting parsing to the user |
| Postel's | Postel, 1980 | Forgive input, clean output | Swallowing real errors |
| Doherty | Doherty & Thadani, 1982 | <400ms; optimistic UI, skeletons | Blocking spinners; slow transitions |
| Peak-End | Kahneman et al., 1993 | Design peaks + endings | Neglecting the finish |
| Aesthetic-Usability | Kurosu & Kashimura, 1995 | Polish earns trust/forgiveness | Masking real usability flaws |
| Von Restorff | von Restorff, 1933 | One distinct focal point | Emphasizing everything |
| Serial Position | Ebbinghaus | Important items at start/end | Burying key action in the middle |
| Goal-Gradient | Hull, 1932; Kivetz 2006 | Progress bars; endowed progress | Resetting/lying progress |
| Zeigarnik | Zeigarnik, 1927 | Checklists; open loops | Endless un-closable loops |
| Cognitive Load | Sweller, 1988 | Cut extraneous load | Hiding essentials (raises load) |
| Selective Attention | Simons & Chabris 1999; Benway & Lane 1998 | Put key info in task path | Banner-styled essential UI |
| Flow | Csíkszentmihályi, 1975 | Fast, clear, uninterrupted | Mid-task modals/upsells |
| Recognition>Recall | Nielsen heuristic, 1994 | Pickers, autocomplete, visible state | CLI-style novice tasks |
| Parkinson's | Parkinson, 1955 | Honest deadlines/timers | Fake urgency |
| Pareto | Pareto / Juran | Prioritize the vital 20% | Ignoring the long tail |
| Occam's | Ockham | Simplest flow that works | Over-simplifying past Tesler floor |
| Loss aversion / Anchoring | Kahneman & Tversky, 1979/1974 | Framing, comparison, defaults | Coercive dark patterns |
| Choice overload | Iyengar & Lepper, 2000 | Curate; recommend a default | Confusing with Hick (speed vs paralysis) |
| Gestalt grouping | Wertheimer et al.; Palmer & Rock | Group via space & regions | Dividers instead of whitespace |

---

## 10. Cross-device application

The laws are universal; their *thresholds* shift by input method and context.

| Law | Mobile / touch | Desktop / pointer | Watch / TV / voice |
|---|---|---|---|
| **Fitts's** | Touch targets **≥44×44pt (iOS) / 48×48dp (Android)**, ≥8px apart — the finger is a fat, imprecise pointer with no hover. Thumb-reach zones matter: primary actions in the bottom third. | Precise cursor allows smaller targets, but still respect ≥24px clickable and use screen edges/corners (infinite targets) the mouse can slam into. | Watch: huge targets, few per screen. TV: D-pad focus order *is* the target model — distance = button presses. Voice: no spatial targets; "distance" is dialog depth. |
| **Hick's** | Small screen forces fewer visible choices — lean on progressive disclosure, sheets, and defaults harder than on desktop. | Room for more options, but still group; menus and command palettes scale choice without scaling decision time. | Severe choice limits — 2–4 options per screen on watch/TV; voice must offer ≤3 spoken options or it overflows memory. |
| **Doherty** | Perceived performance is *more* critical — flaky networks. Lean on optimistic UI, skeletons, prefetch, and offline-first; never block the thumb on a round-trip. | Faster networks raise the bar — under 400ms is the floor, 100ms feels instant. | Voice has its own latency budget: a reply must begin <1s or the interaction feels broken; fill with a brief acknowledgment. |
| **Miller / Cognitive Load** | Tiny viewport = brutal extraneous-load budget; chunk aggressively, one primary task per screen. | More room to show context — but don't mistake space for license to clutter. | Watch/voice: hold almost nothing — strip to a single decision; never recite a long list aloud. |
| **Jakob's** | Honor *platform* conventions (iOS vs Android navigation, share sheets, back behavior) — see `platform-conventions`. | Honor web/desktop conventions (menu bar, right-click, keyboard shortcuts). | Honor the platform's own paradigm (watch crowns, TV remotes, voice turn-taking). |

**The through-line:** smaller and less-precise the input, the *larger* the targets, the *fewer* the choices, the *faster* the response must feel, and the *less* the user can hold in memory. Design for the most constrained context your screen will run in, then expand — not the reverse.

---

## 11. Using the laws — workflow & worked example

The laws map to stages of a design. Reach for them in this order when building or auditing a screen:

| Stage | Question | Laws that answer it |
|---|---|---|
| **Structure** | How many things, grouped how? | Hick (count), Miller (chunking), Gestalt/Common Region (grouping), Pareto (which 20% to surface) |
| **Hierarchy** | What's the one focal point? | Von Restorff (distinct focal point), Serial Position (ends), Selective Attention (in the task path) |
| **Targets** | Can they hit / reach it? | Fitts (size, distance, edges), cross-device touch minimums |
| **Flow & speed** | Does it stay responsive and uninterrupted? | Doherty (<400ms), Flow (no mid-task interruptions) |
| **Memory** | Are we making them remember? | Recognition over recall, Miller, Tesler (system absorbs it) |
| **Input** | Are we forgiving? | Postel (liberal input), Tesler (parse it for them) |
| **Motivation** | Will they finish? | Goal-Gradient (progress), Zeigarnik (open loops), Loss aversion (framing) |
| **Memory of it** | How will they recall the experience? | Peak-End (peaks + ending), Aesthetic-Usability (polish → trust) |

**Worked diagnostic — a sign-up form that converts poorly.** Walk the laws as a checklist:

- *Structure:* 14 fields shown at once → **Hick** + **Cognitive Load** violation. Cut to the 4 the account genuinely needs now; defer the rest (Tesler — derive what you can server-side; Pareto — most fields aren't load-bearing for signup).
- *Targets:* "Create account" is a 14px text link bottom-right → **Fitts** violation on the most important action. Make it a full-width 48px button.
- *Speed:* submit shows a blank spinner for 2s → **Doherty** + **Flow** violation. Optimistic transition to the next step; validate in the background.
- *Input:* email rejected for a trailing space → **Postel** violation. Trim and case-fold silently.
- *Memory:* "enter the code from the previous screen" → **Recognition over recall** violation. Carry it forward or show it.
- *End:* success lands on a blank dashboard → **Peak-End** miss. Add a brief "You're in" moment and a clear first action.

Six named laws, six concrete fixes, each defensible in review by its source. That's the point of the catalogue: it turns "this feels off" into "this fails Fitts, here's the threshold."

**The squint/measure tests:** for **Fitts**, drop the design to mobile size and try to tap each primary action with a thumb — if you miss, it's too small or too cramped. For **Hick/Load**, count the decisions visible above the fold; more than ~5 unrelated ones is a smell. For **Doherty**, profile the p95 of every interaction and flag anything over 400ms for an optimistic-UI treatment. For **Von Restorff**, squint at the screen — exactly one element should still read; if two compete, your focal point is split.

---

> Use a law to *diagnose* (name what's wrong and why) and to *justify* (defend a decision in review with its source). They are constraints on human cognition, not preferences — but every one has a dual-use edge. Apply them to serve the user's goal; the moment a law is used to trick rather than help, it's a dark pattern. When in doubt, the canonical attributed reference for the named "Laws of UX" is Jon Yablonski's lawsofux.com; the underlying findings trace to the researchers credited in each block above.