Jakob's Law

Designing a new screen starts with the urge to do it differently. Putting the same icon in the same place feels derivative, and a layout with nothing distinctive about it doesn't look like anyone tried. So the cart moves to the bottom left, or the save button disappears in favor of saving when you click outside the editor.

Attempts like that mostly left users feeling lost rather than impressed. As the web widened, people were already using dozens of products. Someone moving through ten services a day builds their baseline out of how those ten behave. Break the baseline in the eleventh and the eleventh is the one that seems broken.

Support requests after a redesign always looked the same. A wave of "where do I sign in?" arrives the week after launch, and the sign-in button hasn't disappeared — it moved from the top right to the bottom left. The team considered the new spot more visible, but users don't read a screen first. They reach for where they remember it.

Jakob's Law puts that into one sentence. The usability researcher Jakob Nielsen wrote it in 2000: users spend most of their time on products other than yours, so they expect yours to work the way the ones they already know do.

Facing a new screen, people don't start learning from scratch. They match it against the mental model they already hold — the picture of how things work that they carry in their head — and that picture was built by the dozens of products they've used, not by yours.

So a screen is full of questions users already believe they have answers to.

1. Where does the logo take me — to the home screen. Break that promise and people lose their way back.
2. What lives in the top right corner — the account and sign-in. Put a delete action there and people who didn't mean to click it will.
3. What is underlined colored text — a link. Use underlines for emphasis and people click something that does nothing.
4. What does a magnifying glass mean — search. Use it for anything else and you'll need a label next to it, and if you're adding a label anyway, the convention was shorter.
5. Which side do confirm and cancel sit on — it varies by platform, but it has to be consistent within one product. Flip the order between screens and users have to read the buttons every time.

Following conventions means explaining less. A cart icon in the top right needs no caption; moved to the bottom left, it needs some device to point first-time visitors at it. A familiar layout inherits learning that people already paid for somewhere else, which is why a conventional screen can ship with no onboarding tour at all while an unconventional one needs tooltips, a coach mark, and a support article to hold it up.

None of this says there is exactly one right answer. The conventions that matter come from the products your users actually use. Someone whose day runs on local services and someone who lives in international tools can expect different placements, so what counts as convention is something to check against their product set.

The heaviest use is in redesigns, for deciding what not to touch. The screen gets redrawn, but sign-in stays put, search stays put, and menus keep opening the way they did. The test for what may change is what this product intends to do better than everyone else. Be different there, and spend convention everywhere else. A document tool can reinvent how comments thread and still keep its sign-in exactly where the last five products put it.

It also grounds decisions in a design system. Buttons, inputs, and alerts start from widely used shapes rather than freshly invented ones, and the product's character comes through color, shape, and tone. The further a signifier — the visual cue that says something is clickable — drifts from convention, the louder that cue has to be.

Usability tests are where violations surface. When participant after participant reaches for one spot and then looks around because nothing is there, that spot is what they learned elsewhere. Four out of five people going to the same place first is an expectation, not a preference, and expectations are worth far more attention than the comments participants make about how the screen looks.

"Let's just do this the way everyone does. Nothing here needs to be new."

An argument against differentiating on interaction mechanics.

"Jakob's Law says the logo should go to the home screen."

Naming the law to turn a convention into a reason.

"If we move this, support volume goes up."

Pointing out that relocating a familiar element gets paid for in customer questions.

The discussion came up at Pagedeck during a redesign of the document list. Noa's version opened a document on a single click — faster than double-clicking, and consistent with the mobile app.

Mia didn't object, but asked to check one thing first. Pagedeck's users keep a file browser and a spreadsheet open next to it all day, and both of those open on a double click. In usability testing, four of five participants double-clicked, and when a single click opened the document they assumed they'd made a mistake and hit back. The team kept double-click to open and used the single click to show a preview beside the list. The familiar action stayed where it was, and the new behavior went into the empty slot.

The most common reading is that the law asks you to copy. It sounds like an instruction to look like everyone else, which is a hard thing for a designer to accept. What the law covers is interaction convention. What to build, what information to show, and what the product feels like are all still yours to decide. The reason to spend conventions sparingly is to keep room for the parts that should be new. Spread novelty across every corner of the screen and people tire out before reaching what the product is actually good at.

Reading it as "conventional means correct" is the other one. Wide adoption looks like validation. But plenty of widespread patterns work against the user. Cancellation buried several steps deep is common across services, and that commonality is no argument for copying it. The law describes what people expect; it doesn't rule on what's right. Whether to follow a given convention depends on what it does for your users.