jakobs-law-ux

---
name: jakobs-law-ux
description: Applies Jakob's Law of UX — users spend most of their time on other sites and apps, so they expect a new interface to work the way the ones they already know do. This skill should be used when designing, reviewing, critiquing, or redesigning any digital interface (website, web app, mobile app, landing page, form, or flow), and especially when deciding whether a design should follow an established convention or break from it. It provides a catalog of the conventions users expect by surface (navigation, forms, e-commerce, auth, search, feedback states, mobile) and a structured review method that produces prioritized, evidence-based findings.
---

# Jakob's Law for UX Design

## The principle

> **Jakob's Law:** Users spend most of their time on *other* sites and apps. This means
> users prefer a product to work the same way as all the other products they already know.
> — Jakob Nielsen, Nielsen Norman Group

Every user arrives with a **mental model** built from thousands of hours on other interfaces
(Google, Amazon, YouTube, iOS, Gmail, Booking.com, their banking app). They expect a new
interface to match that model. When it does, it feels "intuitive" — which really means
*familiar*. When it doesn't, every deviation costs the user attention, time, and trust, even
when the novel design is objectively "better" in isolation.

**The operating rule:** Default to the convention users already know. Spend novelty only where
it creates real, differentiated value — never on the plumbing (navigation, forms, controls,
icons, flows) that users just want to get through.

## When to use this skill

Use it whenever the task involves the *usability* of an interface:

- Designing a new page, screen, component, or flow from scratch.
- Reviewing or critiquing an existing UI ("is this intuitive?", "what's wrong with this page?").
- Redesigning or "modernizing" something ("make this cleaner / more professional").
- Deciding between a familiar pattern and a creative/custom one.
- Diagnosing why users get confused, drop off, or fail to complete a task.
- Building UI in code (HTML/React/etc.) where layout and control choices are being made.

## How to apply it

There are two modes. Identify which the task needs — often both.

### Mode A — Design / build with conventions

When producing or recommending an interface:

1. **Identify the surfaces involved** — e.g. global chrome, navigation, a form, a checkout, a
   search experience. Most screens combine several.
2. **Look up the expected convention for each surface** in
   [references/conventions.md](references/conventions.md) and adopt it as the default —
   placement, labels, icons, order of steps, and behavior.
3. **State the convention being followed and why**, so the choice is deliberate, not accidental.
   E.g. "Logo top-left linking to home, primary nav horizontal across the top — this is what
   users scan for first."
4. **Deviate only deliberately.** Before introducing anything novel, run it through the deviation
   framework in [references/review-rubric.md](references/review-rubric.md). If the novelty isn't
   earning its keep, drop back to the convention.

### Mode B — Review / audit an interface

When evaluating an existing design, follow the structured method in
[references/review-rubric.md](references/review-rubric.md). In short:

1. Inventory the surfaces present.
2. Compare each against the expected conventions in
   [references/conventions.md](references/conventions.md).
3. Flag each mismatch as a finding with a **severity** (Critical / High / Medium / Low), based on
   how central the broken pattern is to the user's task and how strong the violated convention is.
4. For each finding, name the **mental model that's broken**, the **likely user cost**, and the
   **conventional fix**.
5. Deliver findings highest-severity first, each citing the convention it references.

## The single most important question

For any element being designed or reviewed, ask:

> **"Where would a user expect this, and how would they expect it to behave, based on the other
> products they use every day?"**

If the answer and the design disagree, the burden of proof is on the design — not on the user.

## When breaking convention is justified

Jakob's Law is not "never innovate." Breaking a convention is justified only when **all** of these
hold (the framework in [references/review-rubric.md](references/review-rubric.md) expands each):

1. The new pattern delivers a clear, ideally measurable benefit the convention can't.
2. The benefit is core to the product's differentiation — not incidental chrome.
3. The new pattern is still learnable in seconds and self-evident, or onboarded gracefully.
4. The team can validate it with real users rather than assuming it works.

Innovate on the unique value of the product. Keep the path to that value boringly familiar.

## Related laws (use together)

Jakob's Law works alongside other UX heuristics — reach for them when a finding touches their
domain: **Hick's Law** (fewer choices = faster decisions), **Fitts's Law** (size and proximity of
targets), **Miller's Law** (~7 items in working memory), **the aesthetic-usability effect**
(attractive design is perceived as more usable), and **Nielsen's 10 heuristics**. Jakob's Law is
the one that says: when in doubt, match what users already know.