Tesler's Law
Every system has irreducible complexity. The only question is whether the user absorbs it or the product does.
Definition
Larry Tesler's Law of Conservation of Complexity states that once a system has been simplified as far as it genuinely can be, the remaining complexity is fixed. It can be shifted between the user, the interface and the engineering, but not removed.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- A flow has a step users consistently get wrong.
- Support volume clusters on a single form or setting.
- You are tempted to write help text explaining how to fill something in.
- A proposal removes a step, and nobody has said who now does what that step did.
Common mistakes
- Treating removal of a feature as simplification when the need remains.
- Hiding a required decision instead of making it.
- Absorbing complexity in a way that removes user control over an outcome they care about.
The decision this law forces
Tesler argued that an engineer should spend an extra week absorbing complexity if it saves a minute for each of a million users. Framed that way, simplification stops being an aesthetic goal and becomes an allocation decision with a defensible arithmetic.
The failure mode is silently pushing complexity outward. A form that demands the user knows their tax jurisdiction, a date field that demands a specific format, an error that says 'invalid input' without saying which part: each is a case of the product declining to hold complexity that it could hold.
Where complexity can live
| Location | Example | Cost |
|---|---|---|
| The user | Asking for date in DD/MM/YYYY | Errors, abandonment, support tickets, repeated on every use. |
| The interface | Accepting any date format and echoing back the parsed result | More design and edge-case work, paid once. |
| The system | Deriving tax jurisdiction from the address already collected | Engineering effort and maintenance, paid once. |
| Nobody, by removal | Dropping a field that nothing consumes | Free, and always the first thing to check. |
Practical absorptions
- Parse loosely on input and format strictly on display.
- Derive what you can from what you already have: country from a phone prefix, city from a postcode, currency from locale.
- Provide sensible defaults for every option that has a defensible common case.
- Let the interface do arithmetic the user would otherwise do on paper.
- Absorb the retry: queue the action and reconcile, rather than showing a failure the user has to redo.
Deciding who absorbs it
Do
- Absorb complexity into the system when the system can be right most of the time and correction is cheap.
- Show your working when you absorb something, so the user can see what was assumed.
- Leave the decision with the user when being wrong is expensive or personal.
- Write down which complexity you moved and where it went, because it did not disappear.
Do not
- Remove a control and leave the underlying complexity to surface as a support ticket.
- Guess silently on something the user would have answered in two seconds.
- Call a screen simple when the work now happens in a spreadsheet beside it.
- Push complexity onto the engineering team without saying so, and then be surprised by the estimate.
In practice
- i.
Address autocomplete
Checkout and signupA single lookup field replaced five structured inputs. The complexity of postal formats across countries did not vanish, it moved into an address service. Error rates and time to complete both fall substantially.
- ii.
Automatic timezone handling
SchedulingScheduling tools that display times in the viewer's local zone with the original zone available on hover absorb the conversion. Tools that display a raw UTC timestamp push it back onto the reader every single time.
- iii.
The simplification that moved the work
Where the complexity wentRemoving the project field from the time entry form made the form faster and made every weekly report wrong, so an administrator now spends Friday reassigning entries. The interface got simpler and the system did not.
Commonly confused with
Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.
Occam's Razor
PrincipleAmong solutions that meet the requirement, prefer the one that assumes least.
Key difference
Occam's Razor says prefer the solution with fewest moving parts. Tesler's Law says a residue of complexity cannot be removed at all, only moved. One picks between designs; the other decides who carries what neither design can avoid.
Use Tesler's Law when
- Simplifying the screen has quietly pushed work onto the reader.
- The argument is about who absorbs the difficulty.
- Someone is proposing to remove something that has to live somewhere.
Use Occam's Razor when
- Several designs would work and one is more elaborate.
- You are justifying cutting machinery rather than moving it.
- The complexity in question is genuinely avoidable.
Local chart
LAW·005 · Region I · Grid A2
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
The Law of Conservation of Complexity
L. Tesler
Stated by Tesler during his work at Xerox PARC and later at Apple and Amazon. It is an engineering principle rather than an empirical finding.
- [2]
Living with Complexity
D. A. Norman, MIT Press, 2010
Book-length treatment of the difference between complexity and confusion.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Applied through
Where this shows up as a concrete interface decision.
- Form Labels and Help TextWRT·009 · UX writing
Practical example
A worked decision where this was the deciding factor.
- Whether to Require an Account at CheckoutCASE·001 · Case study
Check your work
Review passes that test whether this was done properly.
- Form UX ChecklistCHK·001 · Checklist
Related concept
Connected closely enough to change how you apply this.
- Aesthetic and Minimalist DesignHEUR·008 · Heuristic
- Error PreventionHEUR·005 · Heuristic
- Flexibility and Efficiency of UseHEUR·007 · Heuristic
- Hick's LawLAW·001 · Law
- Postel's LawLAW·012 · Law
- ConstraintsPRIN·009 · Principle
- Progressive DisclosurePRIN·003 · Principle