Every system has a certain amount of complexity that cannot be removed. The only question is who deals with it: the people who build the system, or the people who use it.
Overview
Tesler’s Law, also called the law of conservation of complexity, holds that complexity does not disappear when a design is simplified; it moves. Some of it is inherent to the task. If the interface does not handle it, the user must.[1][2]
Consider sending an email. Someone must provide a recipient and a sender. A well-designed email client fills in the sender automatically and suggests recipients from past messages, so the user deals with less. That convenience did not eliminate the complexity; engineers absorbed it into the system.[2]
The principle is sometimes called the waterbed theory: push complexity down in one place and it rises somewhere else.[1]
Why it matters
Many business processes are genuinely complex because of regulations, approvals, data dependencies, and exceptions. Tesler’s Law reframes the design question from “how do we make this simple?” to “where should this complexity live?”
Because a product is built once and used many times by many people, absorbing complexity into the system usually produces a large return. Every minute of effort saved for users multiplies across every user and every use.
Key takeaways
- Identify the inherent complexity of a task, and separate it from complexity the design has added.
- Let the system carry the burden where possible: defaults, inference, integrations, validation, and automation.
- Do not hide complexity that people need to manage. Oversimplifying can remove control and lead to errors.
- Reveal complexity progressively, showing advanced options only to those who need them.
- Invest where use is highest. Absorbing complexity in frequently used workflows has the greatest payoff.
In practice
Common patterns in business applications, portals, and internal tools:
Supports the principle | Undermines the principle |
|---|---|
Fields pre-filled from other systems the organization already uses. | Asking people to look up and re-key data stored elsewhere. |
The system calculates totals, dates, and dependencies automatically. | People calculate values manually and enter them. |
Common cases handled simply, with exceptions available when needed. | Every edge case exposed to every user, every time. |
Advanced options available but out of the way. | Necessary controls removed in the name of simplicity. |
Integration effort invested in high-volume workflows. | Users bridging gaps between systems with spreadsheets. |
Questions to ask in a design review
- Which parts of this task’s complexity are unavoidable, and which did we add?
- Where is the user currently doing work the system could do?
- Have we hidden something people genuinely need to control?
- Given how often this is used, is the system taking on enough of the burden?
Origin
Computer scientist Larry Tesler articulated the law while working at Xerox PARC in the mid-1980s. Tesler, who also helped pioneer cut, copy, and paste and modeless editing, later worked at Apple, Amazon, and Yahoo.[1][3]
He described the principle in an interview in Dan Saffer’s book Designing for Interaction, arguing that in most cases the burden of handling complexity should fall on the people building a product rather than on its many users.[1][4]
Related concepts
- Occam’s Razor — remove complexity that is not necessary
- Postel’s Law — the system should absorb variation in input
- Cognitive Load — complexity left to users becomes mental effort
- Conceptual Model — where complexity lives in the system’s model
- Principle of Least Effort — people avoid complex paths
- Contextual Inquiry — observation reveals where users absorb complexity
References and further reading
- Wikipedia. Law of Conservation of Complexity. https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity
- Yablonski, J. Tesler’s Law. Laws of UX. https://lawsofux.com/teslers-law/
- Wikipedia. Larry Tesler. https://en.wikipedia.org/wiki/Larry_Tesler
- Yablonski, J. (2024). Tesler’s Law. Laws of UX. https://lawsofux.com/articles/2024/teslers-law/
- Yablonski, J. Laws of UX (format inspiration for this series). https://lawsofux.com/