Tesler's Law
For any system there is a certain amount of complexity that cannot be reduced. It can only be moved — either absorbed by the system, or left for the user.
Overview
Tesler's Law — formally the Law of Conservation of Complexity — states that every application has an inherent amount of complexity that cannot be eliminated. The question is not whether that complexity exists, but who handles it: the designer and the system, or the user. When complexity is absorbed by the system — through smart defaults, intelligent inference, automation, and careful design — the user experience becomes simpler. When complexity is left to the user, it manifests as confusion, errors, and friction.
This has a direct implication for the 'simplicity as a value' conversation in design: you cannot make a complex task simple. You can only make the interface simpler by taking on more of the underlying complexity yourself. Email clients cannot eliminate the complexity of managing thousands of messages — but they can absorb it through filters, labels, search, and smart sorting, so users don't have to manage it manually. The task is equally complex; the user's experience of it is not.
Takeaways
- 01
Every system has irreducible complexity — the designer's job is to absorb as much of it as possible so users don't have to carry it.
- 02
Simplifying the interface often means increasing the sophistication of the system — better defaults, smarter inference, and more automation are how complexity is moved, not removed.
- 03
Be wary of simplifying the interface at the cost of removing functionality that users need — true simplification absorbs complexity, it doesn't just hide it or delete it.
How to Apply This
Use smart defaults to absorb decision complexity.
Every choice a user must make is complexity transferred to them. Where the system can infer a reasonable default — from prior behaviour, location, context, or convention — it should do so and let users override rather than always requiring explicit input. Smart defaults move the complexity of deciding from the user to the system.
Automate what users should not have to do manually.
Tasks that are repetitive, rule-based, or dependent on system state are candidates for automation. Saving drafts automatically, remembering form entries, pre-filling known information, and suggesting completions all absorb complexity that would otherwise require user effort. Each automation is complexity moved from the user to the interface.
Do not oversimplify at the cost of function.
Removing features to make an interface look simpler is not the same as absorbing complexity — it is offloading complexity onto workflows outside your system (workarounds, other tools, manual processes). Before removing a feature, ask: where does the complexity it was handling go? If the answer is 'to the user,' the simplification is an illusion.
Common Misconception
Tesler's Law is sometimes misread as meaning that interfaces must always be complex. It means the underlying task or system has irreducible complexity — the interface does not. A well-designed interface can be simple precisely because it has absorbed complexity that a poorly-designed one leaves exposed. The law is not a ceiling on interface simplicity; it is a description of where that complexity goes when you push it out of the UI.
Origin
Tesler's Law was formulated by Larry Tesler, a computer scientist at Xerox PARC and later Apple, who spent his career working on making personal computers accessible to non-technical users. Tesler observed that simplicity in user interfaces was not achieved by eliminating complexity but by relocating it — from the user to the system. His work at PARC on modeless interfaces and at Apple on the Lisa and Macintosh was shaped by this principle. The law is sometimes summarised as: 'Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.'
FAQ
- What is Tesler's Law?
- Tesler's Law, also called the Law of Conservation of Complexity, states that every system has a fixed amount of inherent complexity that cannot be eliminated — only moved. In UX, it means that complexity removed from the user interface must be absorbed by the system design, and complexity not absorbed by the system is left for the user to manage.
- How does Tesler's Law differ from Occam's Razor?
- Occam's Razor says to remove unnecessary complexity — the simpler solution is preferable. Tesler's Law says some complexity is necessary and cannot be removed. The two are complementary: Occam's Razor removes what is unnecessary; Tesler's Law tells you what remains after that removal is irreducible, and must be absorbed rather than eliminated.
- What does it mean to 'absorb' complexity in UX?
- To absorb complexity means to move the burden of handling it from the user to the system. Auto-saving, smart defaults, address lookup, format normalisation, and intelligent suggestions all absorb complexity. The user's task is no simpler in principle, but their experience of completing it is — because the system is doing work that would otherwise fall to them.
- Can you give an example of Tesler's Law in a real product?
- Email is a good example. Receiving, organising, searching, and responding to hundreds of emails involves inherent complexity. A basic email client exposes that complexity directly to the user. A well-designed one absorbs it through threading, filters, smart search, and suggested responses — moving the complexity into the system. The task's underlying complexity is the same; the user's experience of it is dramatically different.
