Summary: Jakob’s Law is meant to help UXers design around the way users already think, yet it is often misused to justify bad or overly fashionable designs. This article explains what the law actually means, how it gets twisted in practice, and offers a concrete way to apply it that stays grounded in real user behavior.
Over the past 20+ years of working in UX, I have watched a very specific weird thing play out again and again. Aesthetically minded UX designers often take Jakob’s Law, bend it just enough to fit a design they already like, and then use that warped version of the principle to justify designs that break usability best practices. I have come to think of this as the weaponization of Jakob’s Law.
What makes this especially frustrating is that Jakob’s Law is actually one of the most grounded and practical ideas in UX. It is meant to protect users from unnecessary complexity, not to give UX charlatans cover for playing around with bad ideas. In this article, I want to go back to what Jakob’s Law actually says, explain the way I have always interpreted it, and share a way to spot when it is being misused so that teams can course-correct without turning the conversation into a fight.
Jakob’s Law Refresher
This is Jakob’s Law as defined by Jakob Nielsen himself on the NN/g website:
Jakob’s Law of the Web User Experience: Users spend most of their time on other sites. Thus, anything that is a convention and used on the majority of other sites will be burned into the users’ brains and you can only deviate from it on pain of major usability problems.
In plain language, it is a reminder that people do not learn how to use software by studying each interface in isolation. They build their understanding of interfaces by moving through dozens of apps and sites every day, slowly forming mental models about how things tend to work.
The way I think of it is much simpler. Just don’t reinvent the wheel.
Your users come to your product carrying years of experience with other digital tools. They already know what standard UI controls are supposed to look like, what standard menus do, how standard UI controls behave, and how basic navigation elements usually work. Jakob’s Law is telling us we might as well leverage that existing knowledge in order to make our products more usable by default.
When teams follow Jakob’s Law in this spirit, they reduce cognitive load and make products feel easier to use because the interface lines up with patterns people have already absorbed from the rest of the world.
Users are not standing back, looking at their computer screens like a painting in a gallery, and saying themselves, wow, look at how intuitive this looks. Instead, we know that their eyes are likely where their cursor is, and they’re just trying to get some tasks done quickly and easily. A positive unintended consequence of following Jakob’s Law properly is that you avoid all that nonsense.
How Jakob’s Law Is Weaponized
On the surface, Jakob’s Law sounds so obvious that it feels almost impossible to misuse, yet I have seen it twisted in hundreds of design reviews. The pattern usually shows up in one of two ways.
Bad Pattern 1
The first is what I think of as retroactive justification. A UX designer or a team comes up with a solution they find appealing, whether that is a new interaction, a stripped-down control, or a novel layout. Once someone raises a usability concern, the team starts searching for any example on the internet that looks vaguely similar. As soon as they find one, Jakob’s Law gets invoked as if that single example somehow proves that users are already familiar with the pattern.
For example, I once worked with a team that introduced hidden controls into a dense data table so the interface would look “cleaner.” When users struggled to discover those controls in early testing, someone produced a screenshot from a niche analytics tool that did something similar and claimed that Jakob’s Law justified the choice. What was missing from that argument was any serious look at how often users encounter that pattern across the kinds of tools they actually use.
💡 Key Take Away: One isolated example does not create a mental model, yet Jakob’s Law is often being used as if it did.
Bad Pattern 2
The second and even more common misuse happens when teams copy something from a large consumer product and treat it as a universal best practice. Google is the example that comes up most often. For example, Google products use many icon-only buttons with no labels, so designers will propose unlabeled buttons in a completely different context and then argue that Google has tested it and therefore it must be good UX.
What that line of reasoning ignores is that Google operates under a very different set of conditions than most companies. Their value in the market comes from being ubiquitous. People use Gmail, Calendar, Docs, Search, and many other Google products constantly, which gives Google the ability to introduce new patterns and force users to gradually learn them through repeated exposure across their ecosystem, even when they break common UX best practices.
Most products do not have that advantage. A ride-sharing app, a banking app, or an enterprise tool depends on people being able to complete one-off and infrequent tasks quickly and without confusion. When someone gets stuck in those experiences, they often leave and try a competitor. Decades of usability research have shown that small points of friction can have an outsized impact on whether people stick with a product or abandon it.
💡 Key Take Away: Treating Google, or any other large tech platform, as a model for making design decisions creates a dangerous blind spot because it assumes that your users will invest the same time and patience in learning your interface that they do in those environments.
In the real world, very few products have that kind of margin for error or can afford usability standards as poor as Google’s.
How To Not Fall Victim
The most reliable way I have found to keep Jakob’s Law from being misused is to turn it into a very specific design exercise instead of a vague principle that people can wave around in meetings.
When someone wants to use Jakob’s Law to justify a design decision, I ask them to do three things.
Step 1: Define what the interface is actually doing in plain terms
Not what the feature is called internally, but what the user is trying to accomplish. For example, “select a time for a ride,” “filter a list of transactions,” or “navigate between sections of an account.” This matters because Jakob’s Law applies to tasks, not to brand names. If you cannot describe the user’s goal in a simple way, you are not ready to claim that a familiar pattern exists.
Step 2: Collect examples from at least five products that solve the same kind of problem for similar users
If you are working on a finance app, that means other finance apps. If you are working on a logistics tool, that means other logistics tools. Screenshots from a popular interface only count if they are actually doing the same kind of work your product does. This step forces the conversation out of personal preference and into what users are actually exposed to in the real-world.
Step 3: Lay those examples side by side and look for what repeats
Do most of them use labeled buttons? Do they all put filters in the same place? Do they present options in a fixed, predictable layout, or does the layout change based on context in a way users have to learn? The patterns that show up again and again are the ones users are most likely to have internalized. Those are the patterns Jakob’s Law is pointing you toward.
If the design being proposed lines up with what you see across those examples, then Jakob’s Law probably supports it. If it only matches one or two cherry-picked interfaces, then what you have is a novel design idea, not a familiar one, and it should be treated as something that needs validation through testing rather than defended as a known best practice.
I have used this exact process in design reviews many times, and it changes the tone of the room.
With this context, people magically stop arguing about whether something looks cool and start talking about what users already know how to do.
That shift alone prevents most of the misuse, because Jakob’s Law no longer belongs to whoever can find the flashiest example. It belongs to the collective experience of the users you are designing for.
Conclusion
Here is the way I think about Jakob’s Law after watching it get misused for so long. It is meant to be a user-centered principle that helps teams respect the knowledge users bring with them into a product. When it gets reduced to a way to defend a favorite design or to copy a big tech company without considering context, it stops serving that purpose.
Strong UX work starts from shared mental models and proven patterns, especially in products where users have little patience for confusion.
Jakob’s Law is at its best when it guides teams toward those patterns and keeps them grounded in how people actually use technology day to day.
Thanks for reading! If this connects with something you have seen on your own teams, I would love to hear about it, and I hope it gives you a few new ways to push for design decisions that truly respect how users learn and work.