Tesler's law

Tesler's law, or the law of conservation of complexity, comes from the computer scientist Larry Tesler. On his own website, the law is dated to around 1984 and stated as: "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?"

Why it matters

The law reframes "make it simple" as "decide who carries the complexity." Sending an email needs a recipient, a sender and content. A product can make the user handle all of it, or it can autocomplete addresses, remember the sender and save drafts. The complexity hasn't gone. The team has taken it on.

Tesler argued that this trade usually favors the user. His view became widely known through an interview in Dan Saffer's book Designing for Interaction. As quoted on Wikipedia, he put it this way: "If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalizing the user to make the engineer's job easier."

How to apply it

Do:

• List the decisions a task truly requires, then ask which ones the system can make with good defaults.
• Use smart defaults, inference from context and saved preferences so users only handle what is unique to them.
• Use progressive disclosure for the remaining complexity: simple path first, advanced options available.
• Put contextual help where the hard decisions are, rather than in a separate manual.

Don't:

• Remove options that some users need just to make the screen look simpler. The complexity reappears as workarounds and support tickets.
• Hide important choices behind defaults the user cannot see or change.

Common mistakes

• Simplifying the surface only. Fewer fields on screen can mean more errors later if the system guesses badly.
• Pushing complexity onto support. If users can't do something themselves, someone on your team will do it for them, at higher cost.
• Assuming all complexity is irreducible. Much of it is accidental: confusing flows, redundant steps, inconsistent terms. The law only protects the inherent part.
• Ignoring how users react. Laws of UX notes Bruce Tognazzini's counterpoint that when software gets simpler, people often take on more complex tasks with it.

In AI products

AI moves complexity in new ways. A chat box looks like the simplest possible interface, but the work of specifying a task shifts onto the user's prompt: what to include, what format, what to leave out. Good AI products take some of that back with context the system already has, sensible defaults and suggested prompts.

Agents shift complexity further, from doing a task to supervising one. The user no longer fills in the booking form, but now has to judge whether the agent's choices were right. That oversight is the irreducible part, so design for it: clear plans, concrete approval steps and easy correction.