Tesler’s Law
Some complexity belongs to the task. Design decides who handles it and when.
Complexity rarely disappears. More often, it moves between the person and the system.
A recurring schedule looks simple until holidays, time zones, and exceptions appear. Hiding those rules does not remove them. The product can handle common cases while keeping unusual decisions visible and reversible.
Origin
Tesler's Law is a design maxim associated with computer scientist Larry Tesler. His formulation, dated to about 1984, argues that an application carries inherent complexity and someone must deal with it.
Separate essential complexity from avoidable friction. Unclear labels, repeated entry, and poor defaults do not become necessary just because the domain is difficult.
Let the system handle repeatable work such as formatting, calculation, and known dependencies. Ask the person for judgment only when their input matters.
Keep meaningful control available. Automation should show what it did and provide a safe way to review, change, or undo the result.
Choose where complexity belongs by consequence. A simpler screen is not an improvement if it makes errors harder to understand or recover from.
Digital systems
A scheduling flow with smart defaults
The product applies the team's usual hours and time zone, then surfaces conflicts and exceptions for review. Routine logic stays in the system while the manager keeps control of consequential choices.
Physical signals
A camera in automatic mode
The camera can choose exposure for an ordinary scene, but the underlying optics have not become simple. Manual controls remain available when the photographer needs a different result.
The interface removes visible controls but leaves people guessing about rules, correcting automation, or completing work the system could have handled.
Eliminate needless steps, automate predictable work, and expose the remaining decisions with enough context, control, and recovery.