Tesler's Law: Complexity Never Disappears, It Only Moves
Tesler's law, or the law of conservation of complexity, says every product has some complexity that cannot be removed, only moved: onto the user, or onto the team and the system. Larry Tesler argued the team should take it on, since they pay once while users pay every time. It is a rule of thumb, not a tested law.
What is Tesler’s law? Tesler’s law says that every product has some complexity that cannot be removed. It can only be moved: onto the people using it, or onto the people and systems that build it.
It is also called the law of conservation of complexity. It is one of the laws of UX, and the one most about the team rather than the user: it says who should carry the hard part.
In short
- The claim: some complexity is part of the task itself, and no design can make it disappear.
- The choice: it can sit with the user, or with the designers, engineers and software.
- Tesler’s advice: move it to the builders where you can, because they pay once and users pay every time.
- The caveat: it is a rule of thumb from experience, not a tested law, and moving complexity badly can make things worse.
Where Tesler’s law comes from
Larry Tesler was a computer scientist at Xerox PARC and later at Apple, best known for cut, copy and paste and for interfaces without modes. In the 1980s, working on Apple’s tools for building Mac software, he wanted to persuade Apple’s managers and outside developers to put more effort into making programs simple to use. He framed his case as the law of conservation of complexity.
His point, in short: every application has some complexity that cannot be reduced, and the only question is who will have to deal with it. He argued that an engineer should spend an extra week to save millions of users an extra minute each. Work it out below.
1,000,000 people each losing 1 minute adds up to 16,667 hours, about 417 work weeks, against one week of an engineer's time. The users' time is 417 times larger. This is Tesler's point: it is worth spending the engineer's week to take the complexity away from the users.
For any product with many users, the users’ time dwarfs the builders’. That is the whole case for moving complexity onto the team.
What kind of claim it is. Tesler’s law is a principle drawn from experience, not a result from an experiment. Nobody has measured a fixed amount of complexity in a product. It is a useful way of thinking, and it should be treated as one.
Moving complexity: an example
A delivery address takes six fields. Each step below moves some of that work from the person to the system.
The system does nothing, so the person types all six fields, including a country it could have guessed and a city the postcode already gives away.
At each step the person types less. But the work does not disappear: the system needs to know where the person is, a postcode database, then an address search service, and each must cope with cases it gets wrong. The complexity has moved to the team, which is where Tesler said it belongs.
Other everyday examples:
- Email. Autocomplete fills addresses from your contacts, so you do not have to remember them.
- Payments. The card type is detected from the first digits, so you do not have to choose it.
- Dates. A date picker shows a calendar, so nobody has to guess the format.
- Taxes. Tax software asks plain questions and does the rules itself.
When moving complexity backfires
Tesler’s law does not say that more automation is always better. Two things can go wrong.
Bad guesses move the work back. If the system fills a field wrongly, the person has to notice and fix it, which can be harder than typing it in the first place. Automation is only a gain when its guesses are usually right.
People take on more. The designer Bruce Tognazzini pointed out a twist: when a product gets simpler, people use it for more complex things. For example, make a spreadsheet easier, and people build bigger spreadsheets. The total amount of complexity people face may not fall at all. They just get more done with it.
There is also a design cost. Hiding complexity too well can take away control people need. A camera that sets everything automatically is great until you want a different shot.
How to apply Tesler’s law
- Find the complexity that is part of the task. A delivery needs an address. A payment needs a way to pay. That part cannot go.
- Find the complexity you added. Unclear labels, extra steps and odd formats are not part of the task. Remove them first.
- Move the rest to the system where you can. Defaults, lookups, autocomplete and smart detection.
- Make the guesses good, and easy to correct. A wrong default that is hard to change is worse than no default.
- Keep control within reach. Let people override automatic choices when they need to.
- Weigh the cost. For a tool used by twelve people, a week of engineering may not pay off. For one used by millions, it almost always does.
Try it yourself: automation that guesses
Here is the address form again, as a simple model. Choose how many fields the system fills in and how often its guesses are right. Typing a field by hand counts as one action, and fixing a wrong guess as two.
The system fills 4 of 6 fields and guesses right 90% of the time. In this model, a person makes about 2 typing actions and 0.8 fixing actions: 2.8 in all, against 6 when everything is typed by hand. Most of the work has moved to the system, and its guesses are good enough that people rarely have to fix them.
With good guesses, automation removes most of the work. With bad ones, the person spends their time spotting and fixing mistakes, and at about 50% accuracy it is no better than typing everything. Better guesses often help more than automating more fields.
Tesler’s law and other laws of UX
- Hick’s law: fewer choices are faster, and moving decisions to the system removes choices.
- The Doherty threshold: extra work for the system must not make it slow.
- Progressive disclosure hides complexity until it is needed, without removing it.
- The default effect shows how much a good default carries, and how much a bad one costs.
- Jakob’s law: a familiar pattern is complexity users have already learned somewhere else.
- See all of them in the laws of UX.
Common mistakes
- Pushing the complexity onto users. A form that makes people format phone numbers just right has handed them the system’s job.
- Hiding instead of handling. Tucking options away does not remove complexity; it just makes it harder to find.
- Automating with bad guesses. Wrong defaults cost more than no defaults.
- Taking away control. Automatic is good until people need to change something and cannot.
- Treating it as a law of nature. It is a useful principle, not a measured rule.
Frequently asked questions
What is Tesler's law?
Tesler's law, or the law of conservation of complexity, says every application has some complexity that cannot be removed. The only question is who deals with it: the user, or the people and systems that build the product.
Who was Larry Tesler?
Larry Tesler was a computer scientist who worked at Xerox PARC and Apple. He is known for championing modeless editing and for cut, copy and paste. He described the law of conservation of complexity while working on Apple's software tools in the 1980s.
What is an example of Tesler's law?
An address form that looks up the city from the postcode moves work from the user to the system. The complexity has not vanished: the product now needs a postcode database and must handle postcodes that cover several cities.
Is Tesler's law scientifically proven?
No. It is a design principle drawn from experience, not a finding from experiments. It is useful as a way of thinking about where effort should go.
The UX Foundation Course, free
Become the person in the room who understands the user when everyone else is guessing. 4 chapters, 27 free lessons, no sign-up.
Written by
