Tesler's law: the complexity nobody can eliminate
Tesler's law says every system has complexity that cannot be eliminated, only moved. Learn its origin, what it recommends and how to decide who carries it.
What does it say and where does it come from?
Laws of UX states it this way: for any system there is a certain amount of complexity that cannot be reduced. English Wikipedia goes further: every application has a fixed amount of complexity that cannot be eliminated or hidden, and it must be handled during development or through the user’s interaction.
The name comes from Larry Tesler, a computer scientist specialising in human-computer interaction. According to his Wikipedia page, he joined Xerox PARC in early 1973, where he worked on Gypsy, a word processor with a graphical interface for the Xerox Alto, and developed cut and paste with Tim Mott. He also argued for modeless interfaces. In July 1980 he moved to Apple, where he worked on the Lisa. Laws of UX and Wikipedia say Tesler formulated the idea at Xerox PARC, and describe an interview included in Dan Saffer’s Designing for Interaction. Both sources date the formulation to the mid-1980s, which does not fit his leaving PARC in 1980, so it is safest to say only that it grew out of his work at Xerox PARC and Apple, without fixing a year. Wikipedia adds that it is also called the Waterbed Theory and describes it as an adage of human-computer interaction.
Why does it matter to a designer?
Because almost every design decision is a decision about where complexity gets paid. A form with forty fields can be simplified in the interface, but the complexity then appears in the back-end logic, which has to validate and combine that data. Or the interface can expose the complexity and the person resolves it alone, with more errors.
The law also acts as a brake on the temptation to hide everything. Removing a visible step can move the work onto someone who is not prepared to do it. Designing well means choosing deliberately who carries the complexity and checking that the choice makes sense.
What example does Tesler give?
Laws of UX summarizes Tesler’s position like this: an engineer should spend an extra week reducing an application’s complexity, rather than making millions of users each spend an extra minute dealing with it. Wikipedia records his argument in other words: if a million users each waste a minute a day on complexity an engineer could have eliminated in a week, you are penalizing the user to make the engineer’s job easier. The comparison is direct. The cost of simplifying once in the development team can be far lower than the accumulated cost of complexity paid by many people.
It is not a rule for accepting any complexity. It is a way of working out who is best placed to pay it.
What does it recommend?
Laws of UX summarizes three recommendations that can go into a design review:
- Lift the burden from users as much as possible. If the system can decide a reasonable default value, let it.
- Do not design for an idealized, rational user. People forget, get distracted and use products in a hurry.
- Offer accessible help in the context of use. A tooltip at the moment of doubt is worth more than a thirty-page manual.
These recommendations connect with cognitive load: every decision the user has to make or remember consumes resources. And with design principles, which help decide when to hide and when to show.
Limits of the law
Bruce Tognazzini, cited by Laws of UX and by Wikipedia (his essay is titled The Complexity Paradox), argues that people resist simplification: when an application’s complexity is reduced, users then attempt more complex tasks. It is a serious objection. Removing complexity can open new expectations that the system does not meet.
Moreover, Wikipedia describes it as an adage: an observation from professional practice, useful for thinking but not a measurement. The law does not say how much complexity a system has or how much of it can be moved. To know whether a simplification works, you need to test it with users.
Example
Illustrative example: a flight-booking app asked people to choose among four fare types, each with different conditions, before showing the final price. People abandoned on that screen. The team decided to show the most common fare first as the default, with a clear link to the others. Engineers spent two weeks calculating the combinations of conditions on the server, which had previously been shown in the interface. The complexity did not disappear: it moved into the code, where it belonged. People looking for another fare could still choose it, although it was no longer the first step.
For your next screen: list the decisions the person must make and ask which of them the system could resolve. If the answer is any, that is the complexity that probably should move.
When should you NOT move it?
- When the decision belongs to the user. A choice of personal data or preferences should not be made by the system.
- When the system cannot decide well. A wrong default can be worse than asking for the information.
- When the complexity is legal or a matter of security. Some steps must stay visible even when they are inconvenient.
- When the cost of moving it exceeds the benefit. Sometimes it is cheaper to explain it well.
Common mistakes
- Hiding complexity without deciding who carries it.
- Designing for the ideal user who reads everything and remembers everything.
- Confusing visual simplicity with real simplicity: the step may still exist, only hidden.
- Removing a necessary decision and generating errors that cost more later.
- Assuming a simplification works without testing it.
- Ignoring contextual help when the complexity is unavoidable.
Related in the wiki
For the moment when the person must choose between options, read Hick’s law. And to understand what people expect from a system they already know, Jakob’s law shows how mental models reduce effort. For roles and states, which often concentrate complexity, see roles, permissions and states.