UX laws — the 20 that shape every screen
Gestalt, cognition, and behavior laws with a broken/fixed toggle in each card.
Hick's law
The more choices you show someone, the longer they take to decide. Every extra button, menu item, or option adds thinking time — so cut choices down to what people actually need, and hide advanced ones behind an 'Advanced' section.
Overloaded screens make people freeze or leave. Simple menus feel faster and get used more.
Decision-time calculator · RT ≈ 250 + 150·log₂(N+1) ms
5 visible choices → 638 ms just to decide
Task: open Export data. Hit Start, then your first click stops the clock.
readyEvery extra visible choice adds log₂ decision cost. Progressive disclosure keeps the working set at 3 and hides the rest until asked.
Fitts's law
The bigger and closer a button is, the faster you can click it. Make the important buttons big, put them where thumbs and eyes already are, and keep destructive ones far away from frequent actions.
Tiny, distant targets frustrate users and cause mis-taps — especially on phones.
report-final-v3.txt
Tap Save three times. Delete sits one mis-tap away.
MT ≈ a + b·log₂(D/W+1): a 56px-wide button is roughly 2× faster to hit than a 24px one — and pulling Delete out of Save’s reach ends accidental deletes.
Jakob's law
People spend most of their time on other websites, so they expect yours to work like those: logo top-left linking home, cart top-right, search up top. Innovation in layout confuses; innovation in product features delights.
When a site breaks familiar patterns, users waste effort re-learning basic navigation instead of getting their task done.
Users spend most of their time on other sites. Logo top-left linking home, cart top-right, search up top — convention is a feature; innovate the product, not the navigation.
Law of proximity
Things placed near each other are perceived as belonging together. Group related items with closeness and whitespace; separate unrelated ones with distance — before reaching for lines and boxes.
Users read layout spatially. If the 'Cancel' button sits visually with a form's fields, people click it by accident.
Username
We’ll never post without your permission.
Password
At least 12 characters.
Username
We’ll never post without your permission.
Password
At least 12 characters.
Quiz: which cluster does each element “sit” with? Your eye decides before your brain does.
Same elements, different gaps. Proximity — not lines or boxes — is what groups them; in the broken layout the help text drifts toward the wrong neighbor and the buttons hug the fields.
Miller's law
People can hold roughly 7 (plus or minus 2) items in working memory. Don't demand memorizing across screens — chunk information into digestible groups and keep key info visible.
Forms that ask users to remember things from a previous page cause errors and abandonment.
❌ One endless page3 answers held in memory
Enter the account code (E-4291), the branch number (B-17) and the assignee (R. Alvarez) — they exist only in this sentence. Type all three from memory.
✅ Chunked wizard0 answers held in memory
Step 1/3 — Enter the account code. The value sits right here: E-4291
Step 2/3 — Branch number. Shown beside the box: B-17. Nothing remembered.
Step 3/3 — Assignee, beside the box: R. Alvarez. Zero recall needed.
Working memory holds ~7±2 items — and an instruction 2 fields back is a memory demand, not a label. Chunked steps keep every answer visible at the point of use; nothing to recall, nothing to drift.
Doherty threshold
If a system responds in under about 400 milliseconds, it feels instant and people stay in flow. Slow it down and users feel pain — but perceived speed counts too: show progress spinners and skeletons so waiting feels shorter.
Perceived speed is as important as real speed for user satisfaction.
❌ Blank-screen loadidle
✅ Skeleton + progressidle
Same 1.6 s network in both. The blank box shows nothing for 1.6 s (feels frozen); the skeleton paints in <400 ms, so the wait feels active. Under ~400 ms is where systems feel instant — after that, perceived speed needs progress.
Von Restorff effect
The thing that stands out is the thing that gets remembered and clicked. Use distinctive color, size, or shape for the one element that matters most on a screen — and resist decorating everything.
If everything is highlighted, nothing is. A single clear emphasis drives the action you want.
❌ Trial A — every card highlighted
Five solid buttons, one job. If everything shouts, the eye samples randomly.
Click Upgrade. Any order works — that’s the problem.
✅ Trial B — one dominant CTA
Same screen, same position — one solid green card among muted neighbors.
Click Upgrade. Try to hit it first.
Minimize target distance
The distance between a control and the thing it affects should be small — the button next to the item it acts on, confirmation near the action, feedback right where you clicked. (Companion to Fitts's law, which is about size/closeness to cursor.)
Every extra inch between cause and control adds error and delay.
Serial position effect
People best remember the first and last items in a list or menu. Put the most important items at the beginning and end; bury the rest in the middle.
Middle items get ignored — important links there are effectively invisible.
Peak-end rule
People judge an experience by its most intense moment and how it ended — not by its average. Design the best moment deliberately and make the last step (checkout confirmation, final page) delightful.
A mediocre journey with a great ending feels great; a fine journey with a frustrating ending feels terrible.
Zeigarnik effect
Unfinished tasks stay stuck in our minds more than finished ones. Use it honestly: progress bars, '3 of 5 steps done', saved-state indicators — they pull people back to finish.
Incompleteness is motivating; showing progress converts starters into finishers.
Law of Pragnanz
People interpret what they see in the simplest possible form. So: make the design itself simple — align elements, reduce visual noise, use clear structure so the 'simplest reading' of your UI is the correct one.
Ambiguous, cluttered layouts get misread; users invent wrong structures and get lost.
Law of similarity
Things that look alike are assumed to be alike. Give all buttons of one kind the same look; give different functions visibly different styles.
Users learn a visual language: if every clickable thing is blue, they'll click anything blue — and stop clicking things that look non-clickable.
Law of uniform connectedness
Elements visually connected (by a line, a shared background, a shared border) are seen as related. Use connecting visuals to show relationships and flow — e.g., steps joined by a line, tabs sharing a bar.
Without connection cues, users miss relationships that are obvious to the designer.
Tesler's law
Every system has a fixed amount of complexity. Tesler's law says: move that complexity from the user to the machine wherever possible. Every complexity you remove from the interface has to be absorbed by the engineering.
Every simplification for users is engineering work for you. Know that trade-off consciously instead of pushing complexity onto users by default.
- · Timezone lookup
- · DST rules engine
- · UTC conversion
- · Invite formatting
Postel's law
Be liberal in what you accept from people, strict in what you produce. Accept 'New York', 'new york', and 'NY' as the same answer; but always output clean, normalized data. (Apply carefully: forgiving parsing of *input*, never lenient security checks.)
Rigid forms treat innocent variations as errors and people give up. Forgiving input plus strict internal handling cuts errors without cutting safety.
— nothing savedParkinson's law
Work expands to fill the time available. In UX: don't give users endless steps or fields — people will fill whatever you provide. Ask for the minimum needed, and keep forms short.
Long forms lose users at a predictable rate; every extra field is a tax on completion.
Occam's razor
Among designs that work equally well, the simplest is best. If two solutions both solve the problem, ship the one with fewer parts, fewer clicks, fewer dependencies.
Every extra element is a potential bug, confusion point, and maintenance cost. Simple survives updates and team changes.
Pareto principle
Roughly 80% of results come from 20% of causes. In products: ~20% of features serve ~80% of real usage. Find that core and polish it relentlessly; everything else is secondary.
Teams spend equal effort everywhere and end up with a bloated product where nothing is excellent.
Aesthetic-usability effect
People perceive attractive things as working better — and they are more forgiving of small flaws in beautiful products. Beauty isn't decoration; it buys patience and trust.
Users forgive friction on a beautiful interface but abandon an ugly one for identical flaws.
Front-end-facing security
The security practices whose failure you can trigger from the browser itself.
Escape user content
Escaping means turning special characters into harmless display text, so anything a user posts is shown as words, never run as code. It's the fix for cross-site scripting (XSS).
If a user posts a piece of script code and the site runs it for every visitor, the attacker hijacks everyone's session — the most common hole in user-generated-content sites.
Validate all input
Validation means checking every piece of incoming data: right type? right size? sensible range? expected format? Checking on the server, every time — the browser's checks are decoration.
Bad input doesn't just break pages; it's the delivery method for most attacks and the cause of corrupted data. If it isn't checked at the door, it's trusted, and attackers live in that gap.
Add security headers
Security headers are free instructions your site sends to browsers: don't run injected scripts (CSP), don't let other sites frame you (X-Frame-Options), only talk over HTTPS (HSTS), and more.
They cost nothing to add and blunt whole categories of attacks — especially the ones that slip past your own code.
Force HTTPS
HTTPS encrypts everything between the visitor and the site. Forcing it means any http:// visit is permanently redirected to https://, using HSTS so browsers remember and never try the unsafe version first.
Without HTTPS, anything a user types — passwords included — crosses the internet in readable text, and attackers on the same network can read or rewrite it.
Restrict file uploads
File uploads need a strict bouncer: check the file type, limit the size, rename the file, store it outside the code area, and never let it execute. Serve downloads separately from the app.
A 'profile photo' upload that actually accepts a script file is a backdoor — attackers upload the script, then visit its address and it runs on your server with full privileges.
Trim API responses
Trimming means the server sends back only the fields each caller actually needs — and never extra internals like other users' data, internal flags, or password hashes.
APIs built by dumping whole database rows often leak fields nobody meant to expose. Testers call it 'excessive data exposure' and it routinely leaks personal info through an app that looks fine.
Add bot protection
Bot protection distinguishes humans from scripts: CAPTCHAs, hidden 'honeypot' fields bots fill in but humans never see, and request-signing. It targets the automated traffic that rate limits alone don't fully stop.
Bots create fake accounts, spam reviews, scrape your content, and stuff stolen passwords into your login page — all at machine speed and volume.
Rate limit login
Rate limiting means refusing too many tries in a short window — e.g., 5 failed logins per account per minute, then a wait. It turns password guessing from seconds into years.
Without limits, a bot can try millions of passwords against your login form at full speed. With limits, automated guessing dies.
endpoint state: accepting every try