Tesler's Law: The Conservation of Complexity
Tesler's Law holds that every system has an irreducible amount of complexity — it can be moved but never removed. Learn how to decide where complexity should live: in the design or with the user.
What Is Tesler's Law?
Tesler's Law (Law of Conservation of Complexity), attributed to Larry Tesler — who also invented cut, copy, and paste — states: "Every application must have an irreducible amount of complexity. The question is only who will deal with it: the designer or the user." You cannot simplify complexity out of existence. You can only transfer it.
"Every application must have an irreducible amount of complexity. The only question is: who deals with it — the user, or the designer?"— Larry Tesler / Laws of UX
The Designer vs. User Tradeoff
When you strip a form down to a single email field at sign-up (transferring complexity to the system), you're absorbing complexity on behalf of the user — the backend must infer or ask later. When you present 15 preference toggles upfront, you're transferring that complexity to the user. Neither is universally right — context determines where the burden should sit.
When to Absorb Complexity in the System
- Onboarding flows — minimise user decisions, use smart defaults, ask preferences progressively.
- Addressing forms — Google Maps' autocomplete absorbs the complexity of standardising address formats.
- Recurring tasks — automate what users do the same way every time (scheduled reports, saved filters).
- Error prevention — validate inline rather than batch-rejecting a completed form.
When Users Should Own the Complexity
Power users — developers, data analysts, finance teams — often prefer complexity on their side. Exposing raw SQL, advanced filters, or manual configuration gives them control they actively want. Over-simplifying for power users strips away capability they rely on. The failure mode is designing a consumer-grade experience for a professional tool.
The Designer's Burden
Tesler's Law implies that as you simplify the user's experience, your own design work becomes harder — not easier. The work doesn't disappear; it shifts from the user to the system, the codebase, or the designer's problem-framing. Simple products are never simple to build.
Key Takeaways
- Complexity cannot be eliminated — only relocated between system and user.
- Default to absorbing complexity in the system for general audiences.
- Expose complexity to power users who actively need control.
- Simple user experiences require the most complex design and engineering work.
