With a smartphone camera, a single tap on the screen sets focus and exposure automatically. In the past, photographers had to work out aperture and shutter speed themselves, but now the machine does that calculation for them. So has the complexity involved in taking a photo really disappeared? The principle that answers this question with "complexity does not disappear, it only moves" is "Tesler's Law of Conservation of Complexity."
Put simply, Tesler's Law is the principle that "every system has a certain amount of complexity that cannot be reduced any further, and the remaining question is who takes it on." It was formulated by Larry Tesler, a computer scientist who refined user interfaces at Xerox PARC and Apple, and it is also called the "law of conservation of complexity."
In this article, we will look in turn at the background of Tesler's Law, the three parties who share the burden of complexity, everyday examples, and principles and limitations for applying it in design.
Tesler's Law: Design That Decides Where Complexity Lives
What is Tesler's Law?
At Xerox PARC, Larry Tesler researched "modeless" editing, in which users do not get trapped in particular modes, and in 1980 he moved to Apple, where he took part in user interface work on the Lisa computer. He is also well known for popularizing the cut, copy and paste method that everyone uses today.
In a retrospective essay, Tesler recounted that, against objections that a feature for temporarily holding cut content would add to the development burden, he argued that "it is better to burden the developer than the user." He then refined that argument and, around 1984, summed it up as follows.
"Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it: the user, the application developer, or the platform developer."
The word "conservation" in the law's name comes from the same idea. Just as energy only changes form and never disappears, complexity can be hidden from the screen but not eliminated. It is sometimes also called the "waterbed theory," after a waterbed in which pressing down on one side makes the other side bulge up.
Three parties who share the burden of complexity
According to Tesler's formulation, irreducible complexity ends up being handled by one of the following three parties.
- User: users have to choose settings, memorize sequences and correct mistakes themselves.
- Application Developer: the people who build the product think harder and write more code to spare users the effort.
- Platform Developer: operating systems or development tools provide common features in advance, so that many products share the same burden.
Of these, Tesler was most wary of the choice to pass the burden to users. In an interview included in a book by the designer Dan Saffer, he pointed out that if a million users each waste a minute a day because of complexity that an engineer could have eliminated with one more week of effort, it amounts to punishing users to make the engineer's job easier.
This law has a different focus from Hick's Law, which says that the more choices there are, the slower the decision, and Fitts's Law, which says that the farther and smaller a target is, the harder it is to hit. If those two laws are frameworks for measuring the time users spend, Tesler's Law deals with the question of responsibility: to whom complexity should be entrusted.
Understanding the shift of complexity through simple examples
You can easily see complexity shifting in services we use every day.
(1) The search box
Users type in only a few letters, but behind the scenes calculations follow that correct typos, suggest search terms and rank the results. The system has taken over the effort of coming up with the exact search term.
(2) Address entry
A screen that fills in the rest of the address when you type a postal code or a few letters of a street name is the result of shifting the burden of writing out a long address accurately to the data and development side.
(3) Cars and navigation
In his 2010 book Living with Complexity, Donald Norman explained that the computer systems in cars grow more complex every year, but that thanks to this hidden complexity, driving becomes simpler and safer. Calculating the best route is now also handled not by the driver but by the navigation system.
In all three examples, the user's work has become lighter, but the design and computation on the maker's side have become heavier by the same amount. The total amount of complexity remains the same; only the person carrying its weight has changed.
Applications and limitations in design
To build Tesler's Law into design, you first have to find where the complexity that ultimately cannot be reduced lies in the task. Then it is best to leave only the parts that users must judge for themselves and let the system handle the rest through defaults, auto-fill and step-by-step guidance. Rather than assuming an ideal user who always acts rationally, it is more effective to show short help right where real users get stuck, at the moment they get stuck.
However, hiding all complexity is not the answer. If you hide too much, users lose the means to adjust things as they wish, so it is necessary to divide things up, for instance by offering step-by-step guidance for first-time users and separate advanced settings for experienced ones. The interface designer Bruce Tognazzini also observed that people do not willingly accept a reduction in the complexity of their lives: when a program becomes easier, users take on correspondingly more complex tasks.
Tesler's Law tells us that a simple-looking screen is not the result of eliminating complexity, but the result of someone shouldering that complexity on the user's behalf. Good design can therefore be judged less by how much complexity it has reduced than by where it has placed it.
Makers taking on first the burden that users would otherwise have to carry is the first step toward design for users.
