Tesler's Law

Every system has a complexity that can't be removed — only moved.

Every system carries an irreducible amount of complexity. The only question is who absorbs it — the system or the user. Good design quietly takes on as much as it can.

The law

The Law

Every application has an inherent amount of complexity that cannot be removed. The only choice is where it lives: inside the system where engineers and designers wrestle with it, or out in the open where users must.

"The complexity of a system is conserved.
You can shift the burden between the user
and the system — but you can't make it vanish."
Coined by
Larry Tesler (1984)
Also called
Conservation of Complexity
Core idea
Complexity moves; it never disappears
Two kinds

Inherent vs. Accidental Complexity

Some complexity is essential to the problem — booking a flight really does involve dates, seats, and fares. Accidental complexity is the extra friction we add on top. You can delete the accidental; you can only relocate the inherent.

Essential vs. added friction INHERENT can't remove ACCIDENTAL cut this
Inherent
Essential to the task
Accidental
Self-inflicted friction
Goal
Delete accidental first
The trade

Who Absorbs the Complexity?

Every design decision pushes the burden one way or the other. A blank text field is simple to build but hard to use; a guided flow is harder to build but effortless to complete. The work doesn't go away — someone pays for it.

A see-saw, not a delete button SYSTEM USER
Push to user
Cheap to build · costly to use
Push to system
Costly to build · easy to use
Default
Favor the user
Best practice

Shift Complexity to the System

Smart defaults, autofill, format detection, and inference let the product do the heavy lifting. Every field you can pre-fill or compute is a decision the user never has to make — the burden absorbed where it belongs.

The system does the work (415) 555-0142 auto-formatted San Francisco, CA from ZIP Continue
Tools
Defaults · autofill · inference
Effect
Fewer decisions for the user
Cost
More logic behind the scenes
The trap

You Can't Oversimplify It Away

Strip out essential complexity and it resurfaces as confusion, errors, or support tickets. A flow that hides necessary steps doesn't remove the work — it just leaves the user to rediscover it the hard way.

Hidden ≠ gone still there swept under the rug
Failure mode
Hide essential steps
It returns as
Errors · confusion · tickets
Fix
Absorb it, don't bury it
Technique

Manage It with Progressive Disclosure

When complexity must reach the user, reveal it in layers. Show the common path first and tuck advanced options behind "More." People get a simple surface without losing the depth they occasionally need.

Simple first · depth on demand ▾ Advanced
Pattern
Layered reveal
Show first
The 80% common path
Tuck away
Advanced & rare options

Tesler's Law in the Age of AI

AI is the most powerful complexity-absorber yet — and the most tempting place to hide complexity the user still needs to see.

✦ AI Era

AI Absorbs the Complexity

A model can take a messy, ambiguous request and resolve the steps itself — the ultimate shift of complexity from user to system. "Plan my trip" replaces a dozen forms. The burden moves further toward the machine than ever before.

One ask, many steps absorbed
Plan a 3-day trip to Lisbon under $1,200
Comparing flights, hotels, and routes…
Describe what you need|
Shift
Forms → intent
Absorbs
Steps · choices · synthesis
Upside
Effortless for the user
✦ AI Era

The Risk: Complexity Goes Hidden

When the model absorbs everything, the necessary parts can vanish too — the assumptions, trade-offs, and edge cases the user actually needed to weigh. Conservation still holds: surface what matters, with sources, controls, and an undo.

Black box vs. glass box ? opaque undo explainable
Risk
Hiding what users must weigh
Keep visible
Assumptions · sources · controls
Safety net
Undo & override
Further Reading