Some fundamental laws of UX

5 well-established principles that should guide any project

Every field of human activity has a set of principles, discovered and tested by many practitioners over a long time. Such collective knowledge drives the profession forward and helps new professionals to avoid the mistakes of the past.

Is there anything like this for user experience? Compared to other professions, UX design is a baby. Ten years ago, you wouldn’t tell your neighbor that you’re a content strategist or a UX researcher — it would confuse them. And yet people have been designing software for more than half a century now. For instance Xerox PARC, famous pioneers of the Graphical User Interface, was founded in 1969, and there were companies writing software before them.

The principles I’ve collected in this post are not objective, perfect laws (like the laws of physics) that always work regardless of the situation. They are insights that came to us from those pioneers and researchers who observed and tried to understand people’s behavior. But similar to the laws of physics, ignoring them will likely cause you bumps and hurdles.

Gall’s law

John Gall is known for his book The Systems Bible, in which he offers practical principles of systems design based on experience and anecdotes. The point he makes multiple times throughout the book is known as Gall’s law.

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

This principle is directly related to our work. Any software is a complex system that involves many different components: technologies, use cases, features, and users themselves. Creating something that complex from scratch is a difficult task. You will be making assumptions that won’t be tested until the product is live — and getting your core assumptions wrong leads to unavoidable failure. The more complex the product, the harder it is to get everything right.

This is why Minimal Viable Product (MVP) is such an important concept in software development. It forces the team to build a simple working system first and enhance it after. When I say working system, I don’t mean technically functional. The working system is the one that achieves its goal and creates value for its users. Start with an MVP, develop iteratively in small steps, reuse known-to-be-working modules, and frequently ensure that the result is still working.

To learn more about system design I highly recommend you check out The Systems Bible.

Conway’s law

Have you ever used software where the look-and-feel was so different from the marketing page that convinced you to try it, that it left you wondering if you downloaded the wrong thing? It’s Conway’s law in action. Your experience was affected by the organizational structure of the company that built the product.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

Melvin E. Conway is a software engineer who first noticed that, in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it.

Managing a large number of employees is challenging, and most companies organize themselves in smaller units tasked with different aspects of the business. This structure increases efficiency and clarifies accountability. Unfortunately for us, user journeys often cut across several business areas, and it might feel broken if no one supervises the journey in its entirety. Even if each unit holds a high quality bar, the entire user experience might feel quickly glued together from separate components.

The same might happen within one team if designers who work on different features don’t communicate enough, or are simply too afraid to step on each other’s toes and raise concerns about inconsistencies.

Be mindful of how parts of your organization reflect the essential parts of the product. Ensure shared vision of user experience and strong communication between teams.

Parkinson’s law

The same job can require a vastly different amount of time and effort. For instance, you can make dinner in either 30 minutes or 3 hours. Of course, you are not going to cook a dish that requires 20 steps and several hours of waiting, unless it’s a weekend and you have more time… Here we go, Parkinson’s law in action:

“Work expands (complicates) so as to fill the time available for its completion.”

The second-order effect you can draw from this is that without a time limit, you can spend more time on a task than is actually required. It becomes especially important in a multi-step process. Let’s say you have two weeks to redesign a website. If you don’t plan how much time you have for each step, by the time you finish with research, you might not have enough time for design.

I am not saying that you can get the same output from a day of work that you can get from a week. But without considering time, you can default to cooking a multi-course dinner even when what you need is a sandwich.

Murphy’s law

“Anything that can go wrong will go wrong.”

Similar to Gall’s law, this adage, coined by aerospace engineer Edward Murphy, suggests a correlation between a system’s complexity and its chances to fail. The more components the solution relies on, the more steps it asks a user to follow, the more explanation it requires, the more likely it won’t work. The same principle can be applied when analyzing the development process. The more objectives your project has, the more people or teams that are involved, the more dependencies you have, the more assumptions you’re making…the more likely something will go wrong. In both cases, other things being equal, the simpler, more straightforward path has a better chance of success.

Tesler’s law

“Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.”

Also known as the law of conservation of complexity, this statement asks who should be exposed to complexity. Should a developer add complexity to the code to make the interaction simpler for the user, or should the user deal with an unfriendly interface so that the software code can stay comprehensible? Of course, as a UX team, I want to choose the former; however, there is no one-size-fits-all solution. Sometimes, adding code might affect the reliability and scalability of the system, not to mention the project timeline, and the user might not even notice the complexity passed to them. Tesler’s law shows why designing in silos and throwing mockups “over the fence” never works. Building software requires considering tradeoffs for both a user and a system, and you have to work closely with your developers to find the balance.

For those interested in learning more about good guiding UX principles, I recommend visiting https://lawsofux.com for an expanded list. And those who want to see more of the cartoons I used to illustrate this post are welcome to check out my personal visual UX blog @accordingtoelon.