Laws of UX (Hick's, Fitts's, Jakob's, Miller's, Tesler's, Postel's)
Six research-backed principles that explain how humans perceive, choose, and act — and how applying them separates intuitive products from frustrating ones.
11 min read
Predicted decision time
0.35s
The time to choose grows logarithmically with the number of options (T = b·log₂(n+1)). Group, prioritize, or progressively disclose choices instead of exposing them all at once.
The full lesson
Six concise laws sit at the intersection of cognitive psychology and interface design. They were not invented by UX designers — they were borrowed from experimental psychology, human-factors engineering, and information theory.
What makes them valuable is that they describe predictable human behavior. Given the same conditions, people respond the same way, regardless of culture or experience level. Once you know these laws, you stop guessing why a design feels fast or slow, clear or confusing — and start engineering those qualities on purpose.
Why Laws Matter More Than Opinions
Design discussions too often stall in preference debates. Laws give you shared, testable ground.
When a stakeholder wants to add five more items to a navigation bar “because everything is important,” Hick’s Law is a cleaner rebuttal than taste. When a developer asks why the submit button needs to be larger, Fitts’s Law provides the answer — and the math behind it.
That said, laws are descriptive, not prescriptive. They model average human behavior under controlled conditions. Real users bring context, prior experience, and emotional states that shift those baselines. Use the laws to spot risk zones and set design constraints — not as mechanical formulas that override user research.
Hick’s Law: Complexity Grows With Choice
The principle: The time it takes to make a decision increases with the number of choices available. William Edmund Hick and Ray Hyman formulated this in the 1950s. It is sometimes written as T = b * log2(n + 1), where T is decision time and n is the number of equal options.
The relationship is logarithmic — and that detail matters. Going from 1 option to 2 roughly doubles decision time. Going from 8 to 16 adds far less extra time than that first doubling. This means reducing choices pays off most at the low end. Cutting two items from a four-item menu is more valuable than cutting eight items from a twenty-item menu.
Where it shows up in UI:
- Navigation menus with too many top-level items
- Settings screens that expose every toggle at once
- Onboarding flows that dump the full feature set on day one
- Call-to-action sections with four competing buttons
How to apply it: Progressive disclosure is the primary pattern. Show the smallest useful set of choices for the current task. Surface advanced options only when context demands them.
Mega menus on desktop work well when structured by clear categories — grouping reduces apparent choice. Hamburger menus work on mobile for the same reason. On desktop, hamburger menus fail because hiding navigation adds a step without reducing cognitive load. The user must first remember that options exist, then open the menu to find them.
Do
Don't
Fitts’s Law: Speed Is a Function of Size and Distance
The principle: The time to acquire a target — tapping a button, clicking a link — depends on the target’s size and how far away it is. Smaller targets that are farther away take longer to hit and produce more errors.
Paul Fitts formulated this in 1954 while studying aimed movements. Every pixel of extra distance and every pixel removed from a target’s hit area has a measurable cost in task time and error rate.
Key design implications:
| Scenario | Fitts’s Law guidance |
|---|---|
| Primary action button | Large, positioned close to where the user’s pointer or thumb naturally rests |
| Destructive actions (delete, cancel) | Smaller and/or farther from the flow to reduce accidental activation |
| Mobile touch targets | Minimum 44×44 CSS pixels (WCAG 2.2 criterion 2.5.8 requires at least 24×24 for AA) |
| Edges and corners of the screen | Effectively infinite width — exploit for persistent toolbars and FABs |
WCAG 2.2 introduced the Target Size (Minimum) criterion (2.5.8) at AA level. It requires interactive targets to be at least 24×24 CSS pixels or have sufficient spacing around them. The older 44×44 recommendation from Apple’s HIG and Google’s Material Design is still the stronger, practitioner-preferred target. Both guidelines formalize what Fitts’s Law predicts: small targets cause errors, especially for users with motor impairments.
The corner and edge trick: Screen edges act as infinite barriers — the cursor cannot overshoot them. This is why macOS puts the menu bar at the very top of the screen (a target you can never miss vertically). It is also why a floating action button in the bottom-right corner of a mobile screen is easier to reach than one floating in the center.
Jakob’s Law: Users Spend Most of Their Time Elsewhere
The principle: Users spend most of their time on other sites. So they expect your site to work the same way as all the other sites they already know. Jakob Nielsen articulated this. It is often summarized as “don’t reinvent the wheel.”
This is the most socially complex of the six laws because it pushes against the desire to stand out. The risk is not uniqueness itself — it is uniqueness in navigation and interaction patterns, where novelty creates friction without adding value.
What this means in practice:
- The logo in the top-left corner links home. Always.
- Search lives in the header, not buried in a sub-page.
- The shopping cart is in the upper-right, not the lower-left.
- Forms read top-to-bottom with labels above inputs.
- Blue underlined text (or a clear equivalent) signals a link.
Where to differentiate: Visual identity, content voice, and product-specific workflows that have no established convention are the right places to innovate. When a pattern already exists, your job is to execute it better than competitors — not to replace it with something novel.
The modern caveat: Jakob’s Law can lock in bad patterns if applied without thought. Placeholder-as-label, hamburger menus on desktop, and carousels all became “what users expect” through repetition — despite measurable usability failures. Apply this law for foundational navigation and interaction patterns. Use research to challenge it when a pattern has documented problems.
Miller’s Law: The Magic Number Seven (Plus or Minus Two)
The principle: The average person can hold about 7 (plus or minus 2) items in working memory at one time. George Miller published this in 1956 in his landmark paper “The Magical Number Seven, Plus or Minus Two.”
The most important update: Later research — notably by Nelson Cowan in 2001 — suggests the real working memory limit is closer to 4 chunks, not 7. Miller’s subjects scored higher because they could group related items into single units (chunking). A phone number like 555-867-5309 is three chunks (area code, prefix, subscriber), not ten individual digits.
Design implications:
- Chunk information. Group related fields in a form with a visual header rather than listing 15 fields in a single column.
- Limit navigation to 5–7 items per level — this aligns neatly with Hick’s Law.
- Break long processes into named steps. A 12-step checkout becomes 4 clearly labeled stages.
- Never make users remember something between screens. If they need an order number on screen 3, show it on screen 3 — do not ask them to copy it from screen 1.
The say-do gap: Users will often claim they can handle more information than they actually can. Self-report is not reliable here. Behavioral data — time-on-task, error rates, scroll depth, drop-off points — reveals true cognitive overload far more honestly than a survey asking “Was this page overwhelming?”
Tesler’s Law: Complexity Is Conserved
The principle: Also called the Law of Conservation of Complexity, formulated by Larry Tesler (of Xerox PARC, Apple, and Amazon). Every application has an inherent amount of complexity that cannot be removed from the system — only moved. You can move it from the user to the developer, from the first interaction to a later one, or from the visible interface to a background process.
This law is a useful check on the naive pursuit of “simplicity.” A one-click ordering system does not eliminate the complexity of choosing a delivery address, payment method, and confirmation. It moves that complexity into account setup and default management, where it is solved once rather than repeated with every order.
Practical applications:
- Smart defaults move complexity from repeated interactions to a one-time configuration step.
- Auto-saving moves the complexity of “did I remember to save?” from the user to the application.
- Sensible form pre-fill (address from profile, saved cards) removes repeated-entry complexity.
- AI-generated first drafts move the complexity of starting from blank to the lighter task of reviewing and editing.
The failure mode: Moving complexity to the developer is fine. Moving it back to the user in a different, less obvious form is not simplification — it is obscured complexity. Apps that use heavy “smart” automation without override mechanisms often fall into this trap. The system makes a choice the user did not want, and recovering from that choice is harder than having made it themselves in the first place.
Postel’s Law: Be Liberal in What You Accept
The principle: Jon Postel wrote this into his 1980 specification for the Transmission Control Protocol (TCP): “Be conservative in what you send, be liberal in what you accept.” Applied to UX, it means: accept human input in the broadest reasonable range of formats, and output data in a strict, predictable format.
This law feels more engineering-flavored than psychological — because it is. But its UX implication is profound.
Form input is the clearest example:
| Input type | Rigid (bad) | Liberal (good) |
|---|---|---|
| Phone number | Rejects “555 867 5309” — requires “5558675309” | Strips all non-digit characters, formats on blur |
| Credit card | Rejects spaces — requires 16 unspaced digits | Accepts spaces and dashes, strips on submit |
| Date | Rejects “June 7 2026” — requires “2026-06-07” | Parses natural language dates to ISO format |
| ZIP code | Rejects “10001-1234” — requires “10001” | Accepts 5-digit or ZIP+4, normalizes internally |
Inline validation errors caused by format rigidity are one of the most common and most preventable usability failures. The user has provided the correct information. Your system refused it because of a formatting preference. That is a system error, not a user error.
Modern best practice: Validate on blur — when the user leaves a field — not on every keystroke and not only on final submit. Submit-only validation forces users to hold errors in working memory while also reading new error messages. That is a double hit to their cognitive budget. Specific, actionable error messages (“Phone number must include area code”) are required over generic ones (“Invalid input”) by both usability best practice and WCAG 2.2 criterion 3.3.1.
Do
Don't
Combining the Laws: A Checkout Flow Case Study
These laws compound in real designs. Consider a checkout flow:
- Hick’s Law → Offer one payment method per screen step. Let the user select their card type before showing the form, rather than displaying every field type at once.
- Fitts’s Law → Make “Place Order” the largest, most prominent button on the final screen. Place the back button farther away and smaller.
- Jakob’s Law → Use the standard address form layout (name, street, city, state, ZIP) in the expected order. Do not reorder fields to match your internal data model.
- Miller’s Law → Show a persistent order summary so users do not need to remember what is in their cart while filling in shipping details.
- Tesler’s Law → Pre-fill address fields from a saved profile. Move the complexity of address management to account settings, where it is solved once.
- Postel’s Law → Accept card numbers with spaces, validate on blur, show specific errors inline.
Each law addresses a different failure mode. Together they cover the perceptual, motor, memory, and input-tolerance dimensions of the interaction.
Common Misapplications to Avoid
Hick’s Law misapplied: Using it to justify removing useful features rather than organizing them. Fewer options is not always better — the right options, well-organized, is the goal.
Fitts’s Law misapplied: Making every button enormous. Visual hierarchy still matters. A screen of equally large buttons is as bad as a screen of equally tiny ones.
Jakob’s Law misapplied: Refusing to evolve established patterns even when research shows they are broken. This law is a prior, not a veto.
Miller’s Law misapplied: Capping every list at exactly 7 items. The law is about working memory under active recall pressure — not a universal page-length rule. A product catalog with 12 visible items is not violating Miller’s Law if users are browsing, not memorizing.
Tesler’s Law misapplied: Using it to justify shipping a poorly designed feature (“the complexity is irreducible”). Irreducible complexity refers to the task’s inherent complexity, not your implementation’s accidental complexity. You can always reduce accidental complexity.
Postel’s Law misapplied: Accepting any input format and then silently failing downstream when the normalization logic cannot handle edge cases. Liberal input acceptance must be matched by robust normalization.