Working in both user experience and product management, we see patterns form around our work and interactions with others. One such pattern is that simplifying a system for users often means moving the complexity to another part of the system. When removing user complexity, that complexity will not be removed from the system but will move from users to the development team.
As a product manager, this becomes crystal clear when you are standing between a user experience designer and an engineer, both looking to you to decide if moving complexity from the user to the system is worth a week or more of the development team’s time.
Originally posted on the Humanist blog.
Seeing this pattern arise over and over, we started to think complexity is similar to energy. The law of conservation of energy states that the total energy of an isolated system remains constant, it cannot be created nor destroyed. Instead, energy transforms from one form to another. With that in mind, we thought there must be a law of conservation of complexity—and it turns out there is.
The law of conservation of complexity, also called Tesler’s Law, states:
Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it. Larry Tesler
In the mid-1980s, while working at Xerox PARC, Larry Tesler realized that how a user interacts with an application was as important as what the application did. Dan Saffer’s book Designing for Interaction includes an interview with Tesler. In the book, Tesler explains how he came up with the law of conservation of complexity:
In the early days of our field, when I worked at Xerox PARC, the idea of user interface consistency was new and controversial. Many of us realized that consistency would benefit not only users, but also developers, because standards could be encapsulated in shared software libraries. We made an economic argument: If we establish standards and encourage consistency, we can reduce time to market and code size.
Later, Larry joined Apple and worked on developing the MacApp object-oriented framework, there he formalized his thinking on complexity and software:
To sell the idea to Apple management and independent software vendors, I came up with the Law of Conservation of Complexity. I postulated that every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.
In the interview, Tesler goes on to explain the source and nature of common mistakes made by new interaction designers and the main difference between senior designers and beginners.
Estimating Value (or Cost) to the User
Back to the original question, “is it worth spending the development team’s time removing complexity for the user?” It depends. According to Tesler, “unless you have a sustainable monopoly position, the customer’s time has to be more important to you than your own.”
Here is one way to estimate value or cost to users for a cost-benefit analysis. In this case, we will calculate the value or cost to users within a week. To do so, multiply the following together:
- Average frequency per week that a user encounters the complexity in question
- Number of active users per week
- Value/Cost, a unit representing what a single user will receive from the change or the cost incurred by users due to the complexity in question.
For example, let’s say users encounter the complexity we can remove three times a week, there are 1,000,000 active users per week, and let’s say this complexity costs users .5 minutes per encounter. We calculate 3 * 1,000,000 * .5 = 1,500,000 seconds or 25,000 minutes or 416 hours or just over 17 days. Moreover, this is just a measure of time returned to users for one week.
In this example, we are estimating value to the user based on a week of using the software, but you can use whatever time frame makes the most sense for your use case—for example, annual or customer lifetime.
You can measure value in a time reduction in a workflow, a dollar value or even utility. Utility is used in microeconomics to represent consumer satisfaction and is handy when considering less tangible benefits or costs of delay, such as ease of use.
Going Simpler
There is another option, removing features can eliminate a level of complexity entirely from the system. Low-value features can add to interface clutter, increasing cognitive load for users—a fancy way of saying it makes people think more than they should have to. Interface clutter results in users hunting for what they need and reduces their efficiency while increasing the perceived difficulty level of the software.
No matter how you do it, removing complexity can improve the value of your software to users, but keep in mind the law of conservation of complexity when making product decisions.
Originally posted on the Humanist blog.
Learn more about how we can help your team remove complexity for your users.