Laws of UX · visual guide

A visual guide to the 24 laws of UX.

Based on lawsofux.com.

01

Aesthetic–Usability Effect

Users perceive aesthetically pleasing designs as more usable. A polished UI is forgiven its rough edges.

Looks broken → feels broken
Looks polished → feels solid
More examples
  • Spend the extra 30 minutes on spacing, type hierarchy, and a real button style — it pays back as forgiveness for slow API calls and odd edge cases.
  • Use design tokens (e.g. --space-1..6, --radius-sm/md/lg) so polish is the default, not opt-in.
  • Don't use this as an excuse to skip usability testing — pretty doesn't fix unusable, it only buys patience.
  • Empty states and loading skeletons deserve the same polish budget as the happy path — users see them more often than you think.
02

Jakob's Law

Users spend most of their time on other sites and expect yours to work like the ones they already know.

"Innovative" reversed nav
ContactPricingDocsHome
Conventional left-to-right
HomeDocsPricingContact
More examples
  • Logo top-left links home. Cart top-right. Underline links. Cmd+K opens search. Don't reinvent these.
  • Match platform conventions — iOS back-swipes from the left edge, web users expect the browser back button to work.
  • Save your novelty budget for the differentiated feature, not the navigation.
  • Use the labels users already know: Sign in, Cart, Settings. A clever rename costs you recognition for zero gain.
03

Mental Model

Users have a learned model of how the world works. Friction is the gap between your system and that model.

Custom controls without semantics
Try ↑/↓ — nothing happens.
Native <input type="radio">
Arrow keys, focus, AT — all work for free.
More examples
  • Reach for native HTML before <div role="…"> — it brings keyboard, focus, AT, and form semantics for free.
  • If you must build a custom control, read the ARIA Authoring Practices for that pattern. Match its keyboard map exactly.
  • "Trash" should empty. "Save" should persist. Don't be clever with verbs.
  • Standard shortcuts stay standard: Cmd+S saves, Cmd+Z undoes, Esc closes. Don't repurpose them.
04

Postel's Law

Be conservative in what you do, liberal in what you accept. Forgive imperfect input; produce strict, predictable output.

Strict — rejects "(415) 555-1234"
Lenient — accepts any format, normalizes
More examples
  • Strip and normalize on submit, don't reject on type. Phone: v.replace(/\D/g,''). Email: .trim().toLowerCase().
  • Accept dates in any reasonable form ("tomorrow", "3/4", "2026-03-04") — chrono-node and friends exist.
  • Validate on blur, not on every keystroke. Show errors only after the user signals "I'm done with this field".
  • Handle paste as a first-class input — credit cards, URLs, OTP codes are usually pasted, so strip spaces and dashes before validating.
05

Hick's Law

Decision time grows with the number and complexity of choices. More options = slower (and worse) decisions.

9 plans, no hierarchy
3 tiers + escape hatch
Free
for trying it out
popular
Pro
most teams
Team
for orgs
See all plans →
More examples
  • Cap top-level choices at ~5±2. Hide the long tail behind "More", search, or a settings page.
  • Highlight a default ("Recommended", "Most popular") — it converts indecision into action.
  • Progressive disclosure: don't show the 47 advanced flags until the user proves they want them.
  • When choices can't be cut, group into 3–5 categories — a 20-item menu becomes 5 sub-menus of 4, and decision time drops with the chunking.
06

Occam's Razor

Among equivalent designs, the one with the fewest elements wins. Every added element is a tax.

12-icon toolbar
Three actions + a menu
More examples
  • For every UI element, ask "what breaks if we delete this?" If nothing breaks, delete it.
  • Default to one primary action per screen. Secondary actions get muted styling. Everything else hides in a menu.
  • Beware "just one more option" — feature creep is mostly a UI debt problem, not a code one.
  • Before deleting, try demoting: lighter color, smaller size, behind a "More" menu. Reversible visual edits let you trial "less" without losing the feature.
07

Pareto Principle (80/20)

Roughly 80% of effects come from 20% of causes. Most of your users only use a small fraction of your features.

All features given equal weight
10 features, equal real estate.
Top 2 dominate; rest hides
Search · Compose · everything else (in menu)
More examples
  • Instrument feature usage. Look at your funnel: 80% of clicks usually hit 2–3 buttons. Optimize those mercilessly.
  • Don't waste design budget polishing rarely-used admin screens. Polish the homepage, the search box, the checkout.
  • Aggregate the long tail: combine 30 rarely-used controls into a single "Advanced" panel.
  • Apply the same logic to performance budgets: the home → checkout path gets the bundle-size diet; admin pages can ship the whole world.
08

Parkinson's Law

Work expands to fill the time available. The same is true of forms, settings, and any UI that doesn't enforce defaults.

12-field checkout
First name—
Last name—
Company(optional)
VAT ID(optional)
Address line 1—
Address line 2(optional)
…+6 more
3 fields + autofill
Email—
Card(autofill)
ZIP(autofill)
More examples
  • Default everything that has a sensible default. Country from IP. Currency from locale. Name from session.
  • Smart inputs: autocomplete, inputmode, address autocomplete APIs, Apple/Google Pay sheets.
  • Audit forms quarterly: every field needs to justify its existence. "Could be useful" is not enough.
  • Combine steps when fields are independent: one screen with three inputs beats three screens with one input each, every time.
09

Tesler's Law (Conservation of Complexity)

Every process has irreducible complexity. The question is who absorbs it: the user, the designer, or the engineer.

User-borne: every edge case becomes a field
User must understand all of this.
Engineer-borne: ask once, infer the rest
We figure out the rest.
More examples
  • When you're tempted to add a field, ask: can the server figure this out? Locale, currency, timezone, plan-from-email-domain.
  • Smart defaults > more options. The "best" UX is the one where the user's only decision is the irreducible one.
  • If complexity must surface, surface it once — don't sprinkle the same question across 4 screens.
  • Spend a week on the parser so the user can type "next Friday at 3". Backend work that hides complexity is the highest-leverage UX work there is.
10

Law of Common Region

Items inside the same bounded region (a card, a box) are perceived as related, even if spacing alone doesn't group them.

Just a list of lines
Alex Kim
Engineer · 3d ago
Priya Patel
Designer · 1w ago
Sam Lee
PM · 2w ago
Each item in its own card
Alex Kim
Engineer · 3d ago
Priya Patel
Designer · 1w ago
Sam Lee
PM · 2w ago
More examples
  • Wrap each logical record in a bordered/backgrounded container. CSS: border-radius + border or subtle background.
  • Don't lean on whitespace alone for grouping when the content varies in length — borders survive ragged edges.
  • Conversely, don't wrap atoms that aren't a unit (e.g. don't card-ify single labels).
  • Avoid card-in-card nesting. Each container adds weight — three deep and the UI starts to look like a Russian doll.
11

Law of Proximity

Objects placed close together appear related. Distance implies separation regardless of style.

Even spacing → no groups
Tight inside, loose between
More examples
  • Halve spacing within a group, double it between groups. The "8/16/32 rule" works: gap:8 inside, 32 between sections.
  • If users repeatedly mis-associate fields, the answer is usually distance, not a heading.
  • Never let unrelated content sit closer than related content.
  • Labels go above the input, not inside it as placeholders. A label that disappears on focus is two memory taxes in one.
12

Law of Similarity

Things that look alike are assumed to do alike. Inconsistent styling for similar functions confuses; consistent styling teaches.

Some links underlined, some not
Read the docs Pricing API reference Changelog
Links look like links; labels look like labels
Read the docs → API reference → Pricing Changelog
More examples
  • One visual treatment per function: all destructive buttons are red, all links share a color, all clickable rows show a hover state.
  • Conversely, never give two different functions the same look — a "save" button and a "publish" button styled identically will be misclicked.
  • Run a "squint test": blur the screen and see if affordances still cluster correctly.
  • Propagate the system: a destructive button in a modal should look identical to one in settings. Same job → same look, everywhere.
13

Law of Uniform Connectedness

Elements connected by lines, arrows, or shared backgrounds feel more related than ones simply close together.

Floating inputs and labels
Name
Role
Wrapped in a connected panel
Name
Role
More examples
  • Use shared backgrounds for related controls (a settings panel, a card, a fieldset) — stronger than spacing alone.
  • Connecting lines work for stepper/wizard UIs. The line tells you they're a sequence.
  • Trees and indented lists use connection (indent + line) to imply hierarchy. Don't fake hierarchy with color.
  • When two elements always work together (label + input, icon + count), connect them with a shared background or border — not just whitespace.
14

Law of Prägnanz

The eye simplifies complex shapes into the simplest interpretation. Reduce ambiguity by reducing visual noise.

Spaghetti chart
2024-01: ▆▃▆▂▆▃▇▂▆▅▇▃
2024-02: ▃▅▇▂▆▅▆▂▇▃▆▅
2024-03: ▆▃▆▂▆▃▇▂▆▅▇▃
2024-04: ▃▅▇▂▆▅▆▂▇▃▆▅
2024-05: ▆▃▆▂▆▃▇▂▆▅▇▃
One number that matters
+18.4%
MRR growth · last 30 days
vs. +12.1% prior period
More examples
  • For dashboards: lead with one big number. Charts are supporting actors; the headline tells the story.
  • Audit your screen: if you removed each element, what would users miss? Ship the edit.
  • Beware decorative SVGs/illustrations that compete with the actual content.
  • Strip chart junk: no gridlines, no 3D, no shadows. The data is the visual; everything else is interference.
15

Von Restorff Effect

An item that visually stands out from its peers is more likely to be remembered (and clicked).

All plans equal
Free
$0/mo
Pro
$12/mo
Team
$48/mo
Pro highlighted = "most popular"
Free
$0/mo
Pro popular
$12/mo
Team
$48/mo
More examples
  • Pick exactly one element per screen to be the "different" one — the primary CTA, the recommended plan. Two competing peaks ≈ no peaks.
  • Use it for empty states ("← Click here to get started") and onboarding moments.
  • Don't abuse with permanent badges. If everything's labeled "NEW", nothing is.
  • Reserve your most saturated color for one job — usually the primary CTA. Spend it elsewhere and the actual CTA fades into the noise.
16

Fitts's Law

Time to acquire a target is a function of distance and size. Big nearby targets are faster than small far ones.

24×18 px, top-right, far from thumb
Full-width primary at the bottom
More examples
  • Tap targets ≥ 44×44 px (Apple HIG) / 48×48 dp (Material). Don't argue with users; they have fingers.
  • Put the primary action where the thumb naturally rests — bottom on mobile, near the cursor's last action on desktop.
  • Screen edges and corners are infinitely "big" (you can't overshoot them). Use them: max bar, dock, close button.
  • Keep related actions close. A "Save" at the bottom of a long form is a Fitts's tax on every edit.
17

Doherty Threshold

Productivity and engagement hold when a system responds in under ~400 ms. Past that, attention drops.

Wait, then reveal (1.5s)
No results
Optimistic, instant + skeleton
Start typing…
More examples
  • Show feedback within ~100 ms. If you can't compute the answer that fast, render a skeleton, optimistic state, or progress indicator immediately.
  • Debounce input handlers, but don't debounce the spinner — start it on keystroke, swap to results when ready.
  • For long ops, show a determinate progress bar (a moving number is better than an indefinite spinner past 2 s).
  • Optimistic UI: update the screen as if the action succeeded, then reconcile on server reply. Failures are rare; instant feedback is daily.
18

Miller's Law

The average person can hold ~7 (±2) items in working memory. Group long sequences to ease recall.

Run-on string
14155551234
Chunked
+1 (415) 555-1234
More examples
  • Format phone numbers, credit cards, IBANs, and OTP codes with separators. Use autocomplete + inputmode.
  • Don't take this as "always show ≤7 items" — that's a misreading. The limit is on items the user must hold in their head, not items on screen.
  • Long lists are fine if they're searchable/scannable. The problem is asking users to remember.
  • Chunk anything memorizable. Order codes are X7-K2P, not 478392831 — humans recall chunks, not strings.
19

Working Memory

Working memory is small, fragile, and easily disrupted. Every context switch costs the user state.

Confirm dialog with no context
Are you sure?
This action cannot be undone.
Confirm dialog that holds the context for you
Delete "Q4_marketing_plan.pdf"?
Shared with 3 people. Moves to trash; restorable for 30 days.
More examples
  • Confirmations should restate what, why, and what happens next. The user shouldn't have to remember which row they clicked.
  • Persist form state on every keystroke — never lose what the user typed because of a navigation, refresh, or session expiry.
  • Don't pop modals over forms. Don't redirect mid-task. For OTPs, set autocomplete="one-time-code" so the OS handles the context switch.
  • Show the user their inputs back at every step — a sticky summary, a sidebar recap. Don't make them scroll up to remember what they picked.
20

Selective Attention

People filter out elements that look like ads, banners, or anything irrelevant to their task ("banner blindness").

Important info styled like an ad
Welcome back, Alex.
⚠️ Your password expires in 2 days. Click here to update!
Your latest reports are ready below.
Inline, in the user's flow
Welcome back, Alex.
Update your password — it expires in 2 days. Update now →
Your latest reports are ready below.
More examples
  • Critical UI must not look like marketing chrome. Avoid bright gradients and dismissable corner toasts for things users actually need to see.
  • Place mission-critical messages inline, in the user's reading path, in the same visual language as the rest of the content.
  • Test by squint: anything that screams "ad" will be ignored, even if it's important.
  • The top banner strip is treated as ads by default. Put critical info in the content column, not the chrome.
21

Serial Position Effect

People remember the first and last items in a list best. The middle vanishes.

Important items buried in the middle
SettingsPricingHomeBlogSign in
Home first, primary CTA last
HomePricingBlogSettingsSign up
More examples
  • Put the highest-value items at the start and end of any list, menu, or sidebar.
  • For tables: most-important column first, action column last. Middle columns are scenery.
  • In feature lists: lead with the killer feature, end with the surprising one.
  • In a nav of seven, items 1–2 and 6–7 get the clicks. Position 4 is where things go to be forgotten.
22

Goal-Gradient Effect

Motivation increases as people get closer to a goal. Show progress toward completion, even if you have to fake the head-start.

"Step 2 of 5" — no visible progress
Set up your account
Step 2 of 5
Visible bar + already-done steps
Set up your account
Email ✓Plan ✓ProfileTeamDone
More examples
  • Always render progress as a bar/percent, not just "step 2 of 5". Brain math is friction.
  • Endowed progress: start the bar partially filled ("You're 20% done!") — measurably increases completion rates.
  • For long flows, break into chunks and show micro-completion (✓ animations) as each finishes.
  • Never add new steps near completion. A surprise step 8 on a "7-step" flow is the most common abandon point.
23

Peak–End Rule

People judge an experience by its peak (best or worst moment) and its end, not the average.

Flat completion — forgettable
✓
Submitted.
Memorable completion — names what happened, hands off the next move
🎉
You're in, Alex!
Your account is ready and your team has been notified.
More examples
  • Spend 2× the polish on the success state vs. the steady state. Confetti, a real summary, a clear "what now".
  • Likewise, eliminate the worst moment — that one slow API call, that one confusing error — even at the cost of average performance.
  • Error states are also peaks. A great error message ("here's what happened, here's how to fix it") gets remembered as competence.
  • The first session is one long Peak: every interaction is being judged. Front-load polish and proof of value before friction (paywall, signup) shows up.
24

Zeigarnik Effect

People remember interrupted or incomplete tasks better than completed ones. Show what's left undone.

Hidden: out of sight, out of mind
Welcome back. View profile →
Visible checklist of what's still undone
Finish setting up your account
✓ Verify email
✓ Add a payment method
✓ Choose a plan
○ Connect a repo
More examples
  • Persistent onboarding checklists with a clear "next step" pull users back to incomplete tasks days later.
  • Show counts of unread/unfinished items in the nav (the dot, the badge). It's not noise; it's a memory aid.
  • Drafts deserve breadcrumbs: "You have 1 unsent draft" beats letting it rot in a folder.
  • Once a task is genuinely done, finish it. A checklist that never clears (now nagging for upsells) trains users to ignore the dot.

That's all twenty-four.

Read Yablonski's full reference →