Tech & AI, Explained

ux-principles

13 min read

UX principles — the short list

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: The handful of UX laws and heuristics that actually shape decisions — not the academic catalog, just the ones that change what you ship.

In plain English

There are thousands of usability heuristics, design patterns, and “laws of UX” floating around. Most of them are interesting; only a few materially change what you build. This entry lists the principles a non-designer who builds webapps actually USES — the mental shortcuts that prevent the most common mistakes.

These aren’t rules. They’re rules-of-thumb. They’re useful precisely because they let you make decisions FASTER than thinking from first principles each time. When you spot one applying to a screen you’re designing, you have a default answer to reach for.

The five most-used in solo modern webapp work:

  1. Hick’s Law — more options = slower decisions. Cut choices ruthlessly.
  2. Fitts’s Law — larger and closer targets are faster to hit. Make important buttons big and near where the eye/cursor lives.
  3. Recognition over recall — show me my options; don’t make me remember them.
  4. Aesthetic-usability effect — pretty things feel easier to use, even when they’re not.
  5. Doherty threshold — interactions under 400ms feel “live”; above that, momentum breaks.

There are dozens more (Jakob’s Law, Miller’s Law, Tesler’s Law, the Peak-End Rule…). They have their moments. The five above carry most of the weight.

This isn’t a substitute for hiring a designer or studying UX seriously. It’s a checklist that prevents the most common solo-developer mistakes.

Why it matters

Three reasons internalizing a handful of UX principles is worth more than memorizing a thousand:

  1. They give you a vocabulary for design decisions. “Why three options instead of seven?” → “Hick’s Law — every extra choice is a measurable cognitive cost.” Having a name for the principle makes it stick.

  2. They prevent the most common mistakes. Solo developers and engineers default to “every option visible, every feature documented, every action discoverable.” The principles point in the opposite, usually-correct direction.

  3. They scale. A handful of well-internalized principles applied across hundreds of screens produces a coherent UX. A scattered hundred specific rules produces inconsistent UX.

The trade-off: principles are heuristics, not laws. Reality is messier. A “perfect” Hick’s-Law interface with one button isn’t usable if that button can’t do enough things. Use them, don’t worship them.

The five (with concrete uses)

1. Hick’s Law — more options take longer

Statement: The time to make a decision increases (logarithmically) with the number of choices.

In practice:

  • Navigation menus with 12 top-level items are slower than ones with 5
  • Settings pages with every option visible overwhelm users; grouping into categories helps
  • “Sign in with Google / Sign in with email / Sign in with username / Sign in with magic link” — pick the canonical path; bury the others
  • A form with 20 fields paralyzes users; break into steps, hide optional fields

When to apply:

  • You have a screen with many possible actions
  • Users are spending time scanning instead of doing
  • A new user looks at the screen and asks “where do I start?”

Counterpoint: Power users sometimes WANT density. A code editor’s command palette has thousands of options and feels fast. The Hick’s Law mitigation: search.

2. Fitts’s Law — bigger and closer is faster

Statement: Time to hit a target is a function of distance and size. Closer and larger = faster.

In practice:

  • Primary buttons should be LARGE (44 px minimum on touch; ideally larger)
  • Primary buttons should be NEAR the user’s expected position (under a form, not in a corner)
  • Secondary buttons should be smaller and less prominent
  • On a phone, primary actions go LOW (within thumb reach), not at the top
  • The “X” close button should be findable WITHOUT precise aiming — corners with edges (infinite Fitts target) work well

When to apply:

  • Designing button layouts
  • Placing primary CTAs
  • Sizing icon buttons (avoid 16 px — too small for fingers and tiring for mouse users)

Counterpoint: “Bigger = better” has limits. A 200×200 px button is too large; it dominates a layout and looks broken. The principle says PROPORTIONAL — match size to importance.

3. Recognition over recall — show me what’s available

Statement: People recognize options faster than they recall them from memory.

In practice:

  • Visible navigation > hidden menus
  • Dropdowns showing all options > “type to find”
  • Recent items, suggested items, recommendation chips > “remember what you wanted”
  • Icons + labels > icons alone (unless the icon is universal like ✕)
  • “Save changes” button visible > “press Ctrl+S to save (we promise this is true)”

When to apply:

  • A user has to remember something between screens
  • A pattern is “if you know the keyboard shortcut you can do this”
  • An interface relies on muscle memory rather than visible cues

Counterpoint: Visible everything is its own problem (see Hick’s Law). The balance: show the right options at the right time. Progressive disclosure.

4. Aesthetic-usability effect — pretty things feel easier

Statement: Users perceive aesthetically pleasing interfaces as more usable, even when objectively identical to ugly ones.

In practice:

  • Polish matters even when functionality is equal
  • Consistent visual hierarchy (typography, spacing, color) builds trust
  • A clean, well-spaced form feels easier than a cramped one with the same fields
  • Loading states with thoughtful animations feel faster than instant-but-jarring transitions
  • Empty states should be designed, not blank

When to apply:

  • The product feels “right” technically but users don’t like it
  • First impressions matter (landing pages, signup flows)
  • Justifying time spent on polish vs new features

Counterpoint: Beautiful but broken is worse than ugly but functional. The aesthetic-usability effect ASSUMES the thing works. It’s a multiplier on usability, not a substitute.

5. Doherty threshold — speed matters under 400ms

Statement: Interactions completing in under 400ms keep users in flow; above that, attention drifts and users assume the system is broken.

In practice:

  • Page transitions should be near-instant (under 200ms feels native)
  • API calls that take longer need a loading indicator within 100ms
  • Above 1 second, show progress (spinner with progress text); above 10 seconds, give an ETA
  • Optimistic UI (update the screen BEFORE the server confirms) makes 800ms feel like 100ms
  • ISR / cached pages should be the default for any page that doesn’t need fresh data per request

When to apply:

  • A user action feels “laggy”
  • An async operation has no feedback
  • Polling / refresh patterns leave users wondering what happened

Counterpoint: Some tasks are genuinely slow (file uploads, AI inference). For those, show progress; don’t pretend they’re fast.

The next tier — also worth knowing

Jakob’s Law — users prefer familiar patterns

People spend most of their time on OTHER websites. Don’t reinvent the basics: a logo top-left links home, a hamburger means a menu, blue underlined text means a link, a shopping cart icon means a cart. Innovation in interaction patterns is usually friction, not delight.

Miller’s Law — 7±2 chunks at once

Short-term memory holds about 7 items. Group related options into chunks of 5-9; subdivide if more. Phone numbers (xxx-xxx-xxxx) are this principle in action.

Tesler’s Law — complexity is conserved

Every system has irreducible complexity. The choice is WHERE it lives: in the product, hidden from the user, or on the user, exposed in the interface. Good design moves it into the product. Bad design pushes it onto users.

The Peak-End Rule — beginnings and ends dominate memory

Users remember the peak moments (best and worst) and the ENDING of an experience disproportionately. A long-loading screen with a delightful animation feels okay. A signup flow that ends with “we sent you an email” feels worse than one that ends with “you’re in — start here.”

Goal-gradient effect — progress accelerates near the end

Showing progress (1/7, 2/7, …) makes users push through tasks they’d otherwise abandon. The closer the apparent goal, the harder users work.

The principle of least astonishment

Software should behave the way the user reasonably expects. A button labeled “Save” should save. A link to “Settings” should go to settings, not log the user out. Surprising behavior is almost always bad behavior.

A concrete example: redesigning a feature

Suppose you’re building a “search” feature in a Bible Quest-style app. Bare implementation:

[Search box]
[Submit button]

Apply principles:

Hick’s Law — the user has one main action; good. Don’t add advanced search options visible by default; tuck behind “Advanced.”

Fitts’s Law — the search box should be LARGE (44 px tall minimum on touch), centered (where the eye lands), with the input clearly the primary action. The submit button can be visible OR pressing Enter can submit — make at least one obvious.

Recognition over recall — show recent searches, popular searches, or category suggestions BELOW the empty box. Don’t make the user remember what’s searchable.

Aesthetic-usability — give it a clean visual identity. Don’t dump a tiny 12-px-padded input into a busy header.

Doherty threshold — search results should appear in under 400ms. If the backend can’t be that fast, show “Searching…” instantly and update when results arrive. Better: type-ahead suggestions with debounced calls.

Result:

┌────────────────────────────────────────────┐
│  🔍  Search the Bible…                      │
└────────────────────────────────────────────┘

Recent: "John 3:16"   "Genesis 1"   "Psalm 23"

Popular: Verses about hope  ·  About forgiveness  ·  About love

Five principles, ten minutes of consideration, one dramatically better feature.

Common gotchas

  • A principle can be wrong for the specific case. Hick’s Law says “fewer options.” Sometimes (a power-user code editor command palette) more options + great search beats few options. The principle is a starting hypothesis, not a verdict.

  • Multiple principles can conflict. Recognition over recall says “show all options”; Hick’s Law says “cut options ruthlessly.” Resolution: show frequently-used recent options prominently; hide rare options behind progressive disclosure.

  • Design by committee defeats principles. A nominally Hick’s-Law-respecting screen with 15 widgets because everyone insisted on theirs isn’t Hick’s Law — it’s politics.

  • A pretty UI is not a usable UI. The aesthetic-usability effect is a perception bias, not a substitute for functionality. Make it work, THEN make it pretty.

  • “Less is more” is its own trap. Stripping back to a single button might feel minimalist; if the button does the wrong thing, “less” is “useless.” Don’t strip below the minimum viable functionality.

  • Patterns are user-specific. Familiarity (Jakob’s Law) means familiarity to YOUR users. A pattern that’s standard for developers is foreign to a 70-year-old new user. Test with real users.

  • Speed matters less if expectations are set. A “file is processing — 2 minutes remaining” message tolerates 2 minutes. The same delay with no feedback feels broken.

  • Animation can save UX or destroy it. A 300ms transition between pages feels polished. A 2-second elaborate animation feels slow. Snappy is the target.

  • Progressive disclosure has costs. Hiding advanced options behind “More” reduces noise but adds clicks for power users. Default to hiding; show when context implies they want it.

  • Forms are where UX dies. Almost every webapp has at least one form that fights users — too many fields, unclear validation, lost progress on errors. UX principles apply with vengeance: cut fields, big inputs, clear labels, validation feedback at the right moment.

  • The Peak-End Rule means error states matter. Users remember errors disproportionately. A graceful error message with a clear next step heals; a bare “Something went wrong” wounds.

  • “Confirm before you delete” is sometimes correct. Hick’s Law says don’t add a step; but a destructive action SHOULD have friction. Undo is even better — let users delete instantly, with a 5-second undo toast.

  • Click targets in dense lists are tricky. A list with 50 rows can’t all have 44 px height. Solution: tap the row anywhere; show the action on the right; mobile shows actions on swipe.

  • Notifications are interruption budgets. Every push, email, or in-app banner costs trust. Use sparingly; users tune out spam channels.

  • Onboarding is its own UX challenge. First-use should reveal what the app does without forcing a 10-step tour. Show, don’t tell.

  • Don’t optimize for power users at the expense of new users. New users dominate; power users are forgiving. If a feature is brilliant for the 5% expert but confusing for the 95% beginner, redesign.

  • Don’t optimize for new users at the expense of regular users. Conversely, an onboarding that gets in the way of returning users every time becomes hostile. Show it once.

  • Settings pages are where neglect hides. Most apps’ settings pages violate every principle. Audit them periodically.

  • AI-generated UI tends to be busy. When asking Claude or other AI for UI code, ask for “clean,” “minimal,” “with whitespace.” Otherwise expect 10 buttons, 5 colors, 3 fonts.

  • Don’t measure UX by your own usage. You’re not representative. You know where everything is. Real users don’t. Test with someone who’s never seen the app.

  • A redesign isn’t always an improvement. Familiar-but-imperfect often beats new-and-different. Make changes for clear reasons, not because the old felt stale.

  • “Mobile” is not “desktop minus stuff.” A great mobile experience makes different choices than a great desktop one. See Mobile-first thinking.

  • Empty states are an opportunity. A blank “no posts yet” page feels broken. An empty state with “Welcome! Create your first post →” feels alive.

  • Loading states matter as much as success states. A spinner with no context = anxiety. “Searching the Bible for ‘hope’…” = patience.

  • Don’t trust user surveys about UX. Users say “I’d use a customizable dashboard” — and don’t. Observe behavior, not opinions.

  • Personality without UX is annoying. A friendly app voice (“Hey there!”) that hides important functionality is worse than a plain interface that’s clear.

  • A11y is not a separate principle. Every UX principle is also an accessibility principle. Big tap targets help motor-impaired users. Recognition over recall helps cognitive load. Color contrast helps low-vision users.

How to USE these principles

A practical workflow:

  1. Sketch the screen without thinking about principles. Get the rough shape.
  2. Pass 1 — Hick’s Law. What’s on this screen that doesn’t need to be?
  3. Pass 2 — Fitts’s Law. Is the primary action the most prominent? Where is the user’s eye/finger going to land?
  4. Pass 3 — Recognition over recall. Are there places I’m expecting users to remember something they shouldn’t have to?
  5. Pass 4 — Speed check. Is anything going to take longer than 400ms without feedback?
  6. Pass 5 — Polish. Now make it look nice (aesthetic-usability).

Five passes, 10-15 minutes per screen, dramatically better outcome than building “what came to mind first.”

See also

Sources

Graph View

Backlinks