Where the Law Actually Comes From
Larry Tesler - the Xerox PARC and later Apple engineer usually credited with inventing cut, copy, and paste - coined the law of conservation of complexity around 1984, while trying to convince Xerox's management and outside software vendors to adopt shared interaction standards. Unlike Fitts's Law or Miller's Law, it was never tested in a controlled experiment or published as a peer-reviewed finding. Its most-cited source is a conversation with designer Dan Saffer, recounted in Saffer's book Designing for Interaction, and Tesler's own site, which restates the law as a settled principle rather than a measured result. Treat it as a sharp, well-argued design heuristic - not an empirical law in the Fitts's-Law sense.
"Every application has an inherent amount of irreducible complexity. The only question is: who will have to deal with it - the user, the application developer, or the platform developer?" - Larry Tesler
The Designer vs. User Tradeoff
Strip a sign-up form down to a single email field and you've absorbed complexity into the system - it now has to infer or ask for everything else later. Present fifteen preference toggles up front and you've handed that same complexity to the user. Neither move is universally correct; the right call depends on who's using the product and how often.
When to Absorb Complexity in the System
- Onboarding: Minimise upfront decisions, apply smart defaults, ask for preferences progressively rather than all at once.
- Address forms: Autocomplete absorbs the complexity of standardising formats so the user doesn't have to think about it.
- Recurring tasks: Automate anything a user does the same way every time - saved filters, scheduled reports.
- Error prevention: Validate inline as the user types rather than rejecting a fully completed form at the end.
When Users Should Own the Complexity
Power users - developers, analysts, finance teams - often want complexity on their side. Raw SQL access, advanced filters, manual configuration: these hand back control that experienced users actively rely on. Over-simplifying for that audience doesn't reduce their cognitive load, it removes capability they need. The failure mode is building a consumer-grade experience for a professional tool.
The Designer's Burden
Tesler's Law implies that simplifying the user's side makes the designer's and engineer's side harder, not easier. The complexity doesn't disappear - it moves into the system architecture, the codebase, or the problem-framing work a designer has to do up front. Products that feel simple are rarely simple to build.
Key Takeaways
- Tesler's Law is a design heuristic coined by Larry Tesler around 1984 - it has no controlled study behind it, unlike Fitts's or Hick's Law.
- Complexity can be relocated between system and user, but it can't be eliminated.
- Default to absorbing complexity for general audiences; expose it to power users who want the control.
- A simpler user experience almost always means more design and engineering work, not less.
