Six Laws of Usability

User Experience Design is about understanding people and how they use software. For a while now I’ve wanted to put together the “laws of usability” — while that name sounds rather pretentious, I want to capture several basic truths about how people use software. Through these researched-backed observations, we can learn more about how to improve the software we develop.

My six laws of usability are:

  1. Users skip the instructions
  2. Users keep the defaults
  3. Users get distracted
  4. Users break things
  5. Users click the shiny button
  6. Users are different

This post will dive into each of these six laws and how, through understanding them, we can improve the software we make.

Users skip the instructions

Research shows that users read as little as 20% of text on webpages that they view [1]. And why should they read any more? Often users are in a hurry, dealing with whatever chaos is currently ruling their day.. Software should enhance people’s lives, not distract from them. That’s why we should design software to minimize instructions and maximize usefulness.

  • Omit needless words — Users often skip long blocks of text and go straight for their goal. Make every word count. [2]
  • Clearly label all actions — Use clear action verbs like “Publish” or “Delete” on links and buttons to ensure that users know what they are doing; “Okay,” “Yes,” and “Submit” are often ambiguous. [3]
  • Provide contextual help — If the user needs to know something, provide that information at the right time where they can easily find it.
  • Make it intuitive — invest effort in making software intuitive, where users do not need to read instructions to use it properly. If users skip the instructions and can’t use the product, they may move on to a competitor.

Users keep the defaults

Research shows that users are pre-disposed to select first, primary, or default options [4]. Even when users have the opportunity to disable or opt-out of a feature, they often do not, especially when additional effort is required. Remember, users lead busy lives. If the product doesn’t work for them, they will move on.

  • Choose smart defaults — Users are unlikely to change defaults, so it is advisable to select a default that the user is most likely to prefer, either based on a statistical average or their own personal profile.
  • Opt-in is more meaningful than opt-out — If you want to capture a user’s genuine agreement to make a difficult to reverse action, make sure that they deliberately opt-in rather than opt-out. The power of this difference has been recognized in GDPR privacy regulations [5].
  • Defaults can be comforting — If the user doesn’t know what to choose, then a default can help them move on to the next step.

Users get distracted

Users are unlikely to be laser-focused on your product. Distractions come up, and when they do, the user may be pulled away from the product for either a short time or even indefinitely.

  • Send reminders — If you need something from a user, let them know. They may have forgotten.
  • Save drafts — If the user has invested significant work into a webpage, make sure that the work they have entered is saved. They may be pulled away and end up losing the data.
  • Users could quit at any time — Build software in such a way that if the user randomly closes their browser, nothing is irrevocably lost. They should be able to pick up their progress later.
  • Don’t rely on memory — Users may have forgotten important instructions or rules. Make sure to remind them if they are about to do something irreversible.
  • Avoid unnecessary distractions — Moving, blinking, colorful, animated, or visually stunning graphics draw the user’s attention. More so when on the periphery of a webpage. Only include these elements if your intend to draw the user’s attention away.

Users break things

Users are good at breaking apps. While no software is perfect, and developers should not be paralyzed in the futile pursuit of perfection, there are still simple steps to take to minimize the damage that users will inevitably do by accident.

  • Avert one-click disasters — The user should be safe to blindly click anywhere on the screen. Even buttons. If the button does something that is difficult to reverse, there should be a confirmation.
  • Scary confirmations should be scary — If an action is going to irrevocably delete hundreds of files or declare nuclear war, then confirmation should be very explicit. Have the user retype text confirming what they are about to do, or at least click an extra checkbox before confirming.

Users click the shiny button

Rather than carefully evaluating all of the options in front of them, users frequently click whichever option seems most likely to immediately solve their problem. I like to think of this as the shiny button. By understanding what users look for, we can affect where they will navigate, and design interfaces that are navigable.

  • Make calls to action shiny — Users are most likely to click large, bright, colorful, raised, glitter-bedazzled buttons. If you want users to click it, make it stand out! By the same token, if you don’t want users to click it, make it less noticeable.
  • Redundancy is useful — while we are trained to eliminate redundancy in writing and code, it is often useful in usability design. If users will look for an option in one of two different places, simply put that option in both. That way, they are more likely to find it.
  • Provide an escape route — Since users will click buttons without considering all options first, they are likely to decide that the page they went to does not offer what they are looking for. Offer them a way back to the homepage or the page they just came from. Sometimes they forget that their browser has a back button.

Users are different

Users are people and people are different. No two products are the same. Designers need to understand their own product’s audience and look to data, not opinions.

  • Trust the data — Whenever possible, use real data to make decisions. Scientific data such as well-designed A/B tests are the most valuable. Data that is specific to your product is better than general data, though academic usability studies and common heuristics are much better than nothing, in the absence of good data.
  • Beware of HiPPOs — HiPPO is a common abbreviation for “Highly Paid Person’s Opinion.” Everyone has an opinion on usability. That includes you, me, developers, stakeholders, and customers. Don’t assume that the average consumer will agree with any one person’s opinion on what constitutes good usability, even if that person is a professional. Use data to make decisions. [6]
  • Know who you’re designing for — Design your product for the people who will actually be using it, and make decisions to benefit the largest number or most important group of users.


I have been designing user interfaces for about seven years now. With each project I learn more about what makes users tick. This post is an ongoing attempt to capture some of that knowledge and share it with others who may be interested. Drop me a line if there’s anything missing. I’m sure there are way more than just six laws of usability.


[1] Nielsen, Jakob. “How Little Do Users Read?” Nielsen Norman Group, 5 May 2008,

[2] Strunk, William, and E.B. White. The Elements of Style. Fourth ed., Longman, 1999.

[3] Babich, Nick. “7 Basic Rules for Button Design.” UX Planet, Medium, 5 June 2019,

[4] Nielsen, Jakob. “The Power of Defaults.” Nielsen Norman Group, 25 Sept. 2005,

[5] “GDPR Consent.” General Data Protection Regulation (GDPR),

[6] Marr, Bernard. “Data-Driven Decision Making: Beware Of The HIPPO Effect!” Forbes, Forbes Magazine, 26 Oct. 2017,