Tesler's Law

The law

Every task carries a share of complexity that cannot be designed away.

Someone has to deal with it. Either the product absorbs it, through engineering, defaults and sensible automation, or the person using the product deals with it, through settings, extra steps and decisions. Design moves complexity around; it rarely deletes it. That is why the law is also called the law of conservation of complexity.

Where it comes from

Larry Tesler worked on user interfaces at Xerox PARC and later at Apple, where he argued that an engineer should spend an extra week on a problem rather than make millions of users spend an extra minute each. He described the idea as the conservation of complexity in an interview Dan Saffer published in Designing for Interaction, first in 2006 and again in the second edition of 2009.

Tesler's point was economic as much as technical. A product is built once and used many times, so effort spent once by the team saves effort repeated by everyone who uses it.

What it means for an interface

• Find the irreducible part. Before simplifying a flow, list what the task genuinely needs: a payment needs an amount, a payer and a payee. Everything else is a candidate for the product to handle.
• Let the system carry the predictable work. Defaults, address lookup, remembered preferences and detected formats all move complexity from the person to the product.
• Do not hide what people must decide. Some choices belong to the person, such as which plan to buy. Burying them behind a "smart" default moves risk onto people without telling them.
• Budget engineering time for it. Absorbing complexity costs the team effort. Treat it as a deliberate investment in the flows people use most, not something to do everywhere.

Examples

Email clients. Sending an email requires routing across servers, encoding and retries. None of that is shown; the person writes an address and presses Send. The complexity still exists, and the client absorbs it.

Address forms. A form that asks for postcode, street, number, district, city and region in six fields hands the work to the person. One that looks up the address from the postcode and lets them confirm it keeps the same data and moves most of the effort to the system.

Tax software. Tax rules are complex and cannot be simplified by the product. Good tax software asks plain questions and does the rule-matching itself; poor software exposes the form's structure and asks people to know which line applies.

Where it is misapplied

• As an excuse for complexity. "The complexity has to go somewhere" does not justify a cluttered screen. Most of what makes interfaces hard is avoidable, not irreducible.
• Automating away control. Absorbing complexity is not the same as making decisions people expected to make. Auto-renewals and auto-selected add-ons shift risk, not effort.
• Treating it as measurable. There is no unit of complexity. The law is a way of thinking about where effort lands, not a formula.
• Ignoring expert users. Some people want the controls. Absorb complexity by default, and leave a way into the detail for those who need it.

Checklist

• The irreducible inputs of each key task are written down.
• Every other input has been checked for a default, a lookup or a remembered value.
• Decisions that carry cost or risk stay visible to the person making them.
• Advanced settings exist for experts but are not required for the common path.
• The team has agreed which flows justify the extra engineering effort.

Related

• Hick's Law: fewer exposed choices is one way the product absorbs complexity.
• Postel's Law: accepting messy input is the product taking work off people.
• Jakob's Law: familiar conventions are complexity people have already learned.
• Patterns: Inline Validation.