I stumbled upon this excellent site about the laws of UX recently: https://lawsofux.com/.

I wanted to comment on a few of my favorites, and also add a couple that I invented that have been useful over the years.

Aesthetic-Usability Effect

Users often perceive aesthetically pleasing design as design that’s more usable.

I think this is abundantly true, and not simply because of the psychological effect of good aesthetics. If someone does not have the time, interest, or resources to make an interface look nice, there is no love in it. You begin to suspect, if it looks substandard, isn’t it likely that corners were cut in other more important ways? It raises suspicions about a site. Also, when one digs down into the details of trying to make a site really beautiful, one discovers details that actually make the site more usable and functional. I think this law works both ways: it makes the user more trusting and accepting, and it makes the creators of the site more likely to create a really good experience.

Doherty Threshold

Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.

What a difference 400 little tiny milliseconds makes! We are talking about less than half a second here. To me, the takeaway here is that everything about the design and engineering of your site must work together to make it actually snappy. On an otherwise excellent and beautiful site, if you have to wait more than that long for a response, a subtle irritation kicks in. This is often a DESIGN problem and not an engineering problem. The site must naturally land you into a place where a list that would otherwise take longer to retrieve and render is filtered, or anticipated, or cached in a way that it is still presented in under 400 ms. This is one of the reasons that I think UX designers should have enough knowledge of full stack processes that they can design with these issues in mind.

There is an interesting corollary here: if you make it too snappy, it can be unnerving. You get that “did this really work?” feeling. It helps to add a bit of animation or delay to give the user the psychological feeling that something actually registered and computed.

Fitt’s Law

The time to acquire a target is a function of the distance to and size of the target.

I love this law, I think about it all the time when I’m creating graphic interfaces. It makes so much sense. The farther you have to go to get to the target, the more likely you are to miss it or overshoot it. And the bigger the target, the easier it is to hit it. It’s a puzzle to figure out the most important things and to cloister them in a convenient way and make them as big as screen real estate allows.

Another thing to think about with this law is that the closer targets are together, the easier it is to acquire the wrong target. You have to be a bit careful about how you group things together if they are targets, because you can create an environment where it is easy to make a mistake. This can create a sort of cloud of fatigue over the site.

The mobile or touch screen version of this law should be a little bit different. It should be, the easier the target is to reach with your thumb or finger, and the larger the target, the easier it is to acquire. On a smartphone, the lower portion of the screen that is reachable by the thumb is the golden real estate. Once you design something where the user must hold the device with one hand and click things with the other, you’ve significantly increased the time to acquire the target.

Hick’s Law

The time it takes to make a decision increases with the number and complexity of choices.

This is such an important concept! Young programmers tend to want to cram as much functionality and convenience as possible onto a screen. Too many choices and too much complexity creates what I call “decision fatigue.” There come to be just too many decisions to make. One of the most important jobs of the UX designer is to create scenarios where many simpler and more obvious decisions are made for you, and truly needful and helpful screens are presented which make a few decisions clear.

Really brilliant designs whittle down choices simply by the nature of the way you arrive at the screen. Once you log in, perhaps the system knows that you usually navigate to a certain part of the site, so it takes you there automatically. Or it filters a data set to items from yesterday since that is what you usually do. Or it filters to a certain region because something important is happening there. Other choices should be possible, but they should not be front and center.

Jakob’s Law

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.

This is increasingly important. Even if you think you can do alerts and feeds better than Facebook on your site, people are familiar with Facebook’s way of doing it. So unless there is an extremely compelling reason to reinvent the wheel, I think we had all better cozy up to the way Google and Facebook and Amazon and Apple and Microsoft do things, and do our creative and delightful best within that paradigm.

Montaigne’s Law

Don’t Easily Change a Law Received

OK, I made this one up. Or rather, Montaigne made it up, and I made up applying it ot UX. As a bit of a corollary to Jakob’s law, if you are working on an existing site or system, people have 100% familiarity with the old one with all of its flaws and bad design – and ZERO percent familiarity with all of your new ideas. The existing system has a million little hidden features that you have definitely missed. People are going to be upset when you change it. At the very least, if you are doing a redesign of an existing system, you have to take a very very close look at what you are replacing. It is existing code that is producing actual revenue – however horrible you may think it is, it has this going for it. It is also very likely that you are not going to be able to change everything at once, so you are going to want to humble yourself and do it in a way that is harmonious with the parts you haven’t changed yet.

Montaigne’s law doesn’t say, “NEVER change a law received.” But there are reasons for strange quirky features and pages and such, and it would do well to take a close look at what those reasons might have been before throwing them out the window.

Tesler’s Law

Tesler’s Law, also known as The Law of Conservation of Complexity, states that for any system there is a certain amount of complexity which cannot be reduced.

This one is good to remember. Every task and every screen actually has a necessary amount of complexity. It harms the functionality of the site if you try to reduce it down beyond this point. I once had to design a mortgage sales pipeline system. There was no easy way to reduce this down to a few fields, and the users resisted attempts to go too far with this. Sometimes people expect automated systems to decide things that you really have to have a human being decide. Our UX designs have to have a certain level of complexity to work well, but no more than that.

Stravinsky’s Soldier’s Law

Work your wonders within pragmatic limits

During WWI, there were obviously no orchestras available for performances in Europe. Stravinsky wrote some of his most daring and creative works during this time – one of which is called “A Soldier’s Tale”. He wrote this work of astonishing originality, worthy of study for its harmonic inventiveness, its timbral brilliance, and its wondrous contrapuntal richness. It requires 13 musicians plus a narrator. Really, it is one of my favorite works. What can we as UX designers learn from this?

You may or may not have the greatest development team to work with. You may or may not have the time and resources to do beautiful working mockups with snazzy animations. You may have to work within the framework of an existing system with not-so-current graphic demands. The true UX genius can take all of this and mix it up into a highly usable easily navigable beautiful experience within those tight boundaries. One of the jobs of the designer is obviously to create designs which can actually be realistically executed. What good is a design which cannot be implemented or cannot be implemented in a reasonable time?