Jakob's law

Jakob's law is a principle from usability expert Jakob Nielsen. NN/g's own wording is: "Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know." The idea goes back to Nielsen's 2000 column End of Web Design, which argued that standard, predictable designs serve users better than distinctive ones.

Why it matters

People do not arrive at your product as blank slates. They bring a mental model built from hundreds of other sites and apps: the logo goes home, the cart is top right, underlined blue text is a link, swiping left on a list item reveals actions. When your interface matches those expectations, users spend their attention on their task. When it breaks them, they spend it relearning basics, and they often blame themselves or leave.

This does not mean every product must look identical. It means the parts people use to get around (navigation, forms, search, checkout, common gestures) should behave the way people already expect.

How to apply it

• Do use established patterns for common jobs: search, login, checkout, settings, file upload, date pickers.
• Do follow platform conventions on mobile. iOS and Android users expect their platform's navigation and controls.
• Do save originality for the parts that are actually unique to your product, such as the content, the brand and the core feature.
• Do give people a transition path when you redesign something familiar. Laws of UX suggests letting users keep access to the familiar version for a while.
• Don't invent new icons or gestures for actions that already have a widely understood one.
• Don't assume a novel layout will be "intuitive" because the team has seen it a hundred times. Test with people who haven't.

Common mistakes

• Reading the law as "copy competitors exactly". The point is to match expectations about how things work, not to clone visuals or business decisions.
• Following a convention that your audience does not share. A pattern familiar to developers or to one region may be new to your users.
• Keeping a bad convention when a clearly better one exists. Conventions do change, and they change when a better pattern spreads across many products. One product breaking a convention alone has a harder time.
• Treating conventions as fixed. What users "already know" shifts over time, so check periodically.

In AI products

Chat assistants are a clear example of conventions forming quickly. A text box at the bottom, a send button beside it, responses appearing above, a list of past conversations in a sidebar and copy or retry actions under each answer are now common across many products. A new AI tool that follows that layout lets people start without instructions. One that moves the input to an unusual place or hides past chats behind an unfamiliar icon makes them hunt.

The harder part is that conventions shape what people expect the AI to do, not only where the buttons are. If users are used to assistants that remember earlier messages in a thread, or that show a stop button while generating, missing those behaviors will feel like a bug. Matching interface conventions also does not fix wrong assumptions about the model itself, so explain what your system can and cannot do.