Tesler's Law

011 min

Tesler's Law at a glance

• What it is: Complexity in a task has a floor. A design can move it between people, but it cannot go below that floor.
• Where it comes from: Larry Tesler, around 1984, by his own website. The wording is his. Most of the retelling is secondhand.
• Apply it by: Asking, for each hard step, which of the three parties should pay for it, and choosing the one who pays once rather than the many who pay every day.
• It backfires when: Hiding a step removes a control that people need, or the extra code costs more than the time it saves.

022 min

What Tesler's Law actually says

Tesler's own statement, published on his personal website, is short:

The statement has two parts. The first is a claim about the task: some complexity is inherent, meaning it comes from what the task is, not from how the screen is drawn. Booking a flight has to handle dates, prices, seats, and payment whatever the interface looks like. The second part is a question about location. Complexity is not a number the designer can set to zero. It is work that someone has to do.

The law names three places that work can land.

• The user. The person learns the options, enters the details, and checks the result.
• The application developer. The team writes code that fills in defaults, validates input, recovers from errors, and handles the odd cases so the user does not see them.
• The platform developer. The operating system, framework, or standard handles the problem once for every application built on top of it.

The causal reasoning is about conservation. If the task needs ten decisions and the screen asks for three, the other seven are still being made. Someone chose a default, a rule, or a limit, and that choice is now inside the code or the platform. If the choice is wrong for a user, the user cannot see it and cannot correct it.

Predicting a case the article never mentions

The law lets you predict what happens when you simplify. Suppose a team removes a form field. You can ask three questions without knowing anything else about the product. Who now supplies that value? How often is the guess wrong? What does the user do when it is wrong? If nobody supplies the value, the field was not inherent complexity and the team removed real clutter. If the system guesses, the complexity moved into the guessing code.

032 min

A worked example: when moving complexity pays for itself

Tesler's argument, as Wikipedia quotes it from his interview in Dan Saffer's Designing for Interaction, is that a small daily cost spread over many users can be larger than a one-off cost to a developer:

The quote supports a simple calculation. The numbers below are this article's arithmetic, not Tesler's. They assume an engineer week is 40 hours, which is 2,400 minutes, and that every user loses one minute each day to the problem.

With one million users, the 2,400 minutes of engineering time are matched by the users' losses in about three and a half minutes of a single day. With ten users, the engineer needs most of a year of use before the change breaks even.

Two things limit this calculation. It counts only build time, so it ignores the cost of maintaining the new code and the bugs it might add. And it assumes the problem is the same for everyone. Where both hold, the table shows why a platform or a popular application should absorb the work, and why a tool used by a small team often should not. A fix made once in a platform also saves the minute for every application built on it, so the user count in the first column is largest there.

042 min

Where Tesler's Law comes from

Larry Tesler (1945 to 2020) was an American computer scientist who worked at Xerox PARC, then at Apple, and later at Amazon and Yahoo, according to Wikipedia's biography of him. His own website gives the wording above and dates it to about 1984. That is the closest thing to a primary source: the person named in the law, on a page he published, describing it as his.

A few points about the attribution should be stated plainly.

• No paper or talk is cited. Tesler's page gives a date of "ca. 1984" and a quote. It does not name the occasion where he first said it. It is not an experiment or a measured result.
• The Saffer interview is secondhand here. Wikipedia, the Laws of UX site, and Tesler's own page all point to an interview with Tesler in Dan Saffer's book Designing for Interaction. The interview's own page is no longer on the live web, and this article could not retrieve an archived copy. The million-users quotation therefore comes through Wikipedia, which in turn cites that interview.
• The Xerox PARC dating conflicts with Tesler's CV. Wikipedia and Laws of UX both say Tesler realized this "while working for Xerox PARC in the mid-1980s". Tesler's own CV lists him at Apple from July 1980 to August 1997, as a section manager in engineering from 1980 to 1986. If both are accurate, the law came from Tesler's Apple years. It is also possible the retellings are loose about where he worked. This article follows his CV.
• The name was already in use by 1998. Bruce Tognazzini, in a September 1998 column, wrote that a friend had "recently reminded me of Larry Tesler's law of Conservation of Complexity". Tognazzini attributed it to Tesler.

Tesler's page also lists independent statements of the same idea by other authors, such as Kay Hammer and Tina Timmerman in 2007 and Dino Esposito and Andrea Saltarello in 2008. The page labels them independent, and they have not been checked against the books here. They show the idea is a natural one, not that Tesler's version is the only source.

052 min

How Tesler's Law shows up in real products

Applied: Let's Encrypt and automatic certificates

A website that uses HTTPS needs a certificate from a certificate authority, which proves that the site controls its domain name. Let's Encrypt describes its goal on its How It Works page: "to make it possible to set up an HTTPS server and have it automatically obtain browser-trusted certificates without any human intervention". An ACME client program, running on the web server, proves control of the domain and requests the certificate.

The task is still there. Domain ownership still has to be proved, and the certificate still has to be issued and renewed. What changed is who does it. The proof moved from the site operator's manual steps to client software, and the issuing moved to an automated certificate authority. That is complexity moving to the platform developer in Tesler's terms.

Applied: passkeys

Passwords make the user responsible for creating, remembering, and entering a secret, and for noticing a fake sign-in page. Google's developer documentation on passkeys describes the change. Passkeys are "bound to a website or app's identity", and "the browser and operating system ensure that a passkey can only be used with the website or app that created them". The page says this "frees users from being responsible for signing in to the genuine website or app".

The complexity of checking that a site is genuine is still there. The browser and operating system now do it. Developers also change what they store: Google's page says they "only save a public key to the server instead of a password". The user's work shrinks, and the work of the platform and the developer grows.

061 min

A second case: modeless editing and a shared standard

A second case, chosen to differ, is the design decision Tesler is best known for.

Wikipedia's biography says Tesler and Tim Mott developed copy and paste while working on Gypsy, and that Gypsy was built around modeless interaction. In a modal editor, a user has to switch into a mode before an action works, and has to remember which mode is active. In a modeless editor, the same actions are always available. The task, editing text, is the same in both. In a modal design the user tracks the state. In a modeless design the program tracks it.

Compare that with the Let's Encrypt case. There, the complexity moved out of one person's routine and into a service shared by many sites. In the Gypsy case, it moved into the program's own logic. The variable that differs is the size of the group sharing the new cost: many independent site operators in one case, one editor's users in the other.

What the contrast teaches is that "the platform developer" is a role, not a company. Whoever builds the layer that many other parts depend on is in that role. A team building a design system plays it for every product team that uses the system's components.

072 min

Applying Tesler's Law

Dan Saffer's Microinteractions, quoted on Tesler's website, gives the method in one sentence: "Start by figuring out where the core complexity lies, then decide which part of that the user might like to have, and when in the overall process." The quote is secondhand here, taken from Tesler's page, and the book itself was not checked. The moves below follow it.

1. 1

   List the decisions in the task.

   Write down every choice the task contains, including the ones the current screen hides.

2. 2

   Assign each decision to a party.

   For each one, mark whether the user, the application, or the platform makes it today. The assignment shows where complexity is already sitting.

3. 3

   Move shared decisions to the shared layer.

   If the same decision is made in many screens or many products, put it in one component, one default, or one standard. A design system is the usual place for this in a product team.

4. 4

   Defer what is rare, do not delete it.

   Show the common choices first and keep the rest one step away. The Nielsen Norman Group describes progressive disclosure this way: it "defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone".

5. 5

   Price the move before you make it.

   Use the break-even table above. If a thousand users each lose a minute a day, a week of engineering pays back in under three days. If ten users lose it, it does not.

Where it stops working

The method fails when the hidden decision is one the user needs to control. An application that picks a default silently, with no way to see or change it, has moved the complexity out of sight, not out of the system. The user still lives with the result, but can no longer act on it. Keep a visible way to override anything the system decides on the user's behalf.

081 min

How to spot Tesler's Law going wrong

Complexity in the wrong place leaves traces you can check in a session recording, a support queue, or a code review.

• Support tickets that ask the same how-to question. If many people ask which setting to choose, the product has handed them a decision the system could have made.
• A default that most users change. If most people change the default in the first session, the system guessed wrong, and the guess is costing everyone a step.
• A growing list of special cases in the code. If the team keeps adding exceptions to make the interface simpler, the complexity is piling up in one module that few people understand.
• Manual fixes downstream. If a simple front end leads to corrections by a support team, the complexity moved to staff.

091 min

Tesler's Law vs. nearby concepts

Tesler's Law is often read as advice to make things simple. It is a statement about where work goes. These neighbours are easy to mix up with it.

Postel's Law is the clearest software example of the same trade. A system that accepts input in many formats is easy for the sender to use and harder for the receiver to write. The complexity did not disappear. It moved to the party that receives.

102 min

Where the evidence on Tesler's Law is contested

Tesler's Law is an adage, and Wikipedia describes it that way. Nobody has measured a fixed quantity of complexity in a product, so "conservation" is an analogy to physics, not a result. The sections below set out the objections a careful reader should hear.

Tognazzini's second-order effect. In his 1998 column, Tognazzini accepts the law and then argues that the story does not end there. "If people will insist on maintaining equal complexity, yet we reduce the complexity people experience in a given task, people will take on a more challenging task." Wikipedia and Laws of UX both report this view. A simpler tool lets users attempt more, so complexity at the level of their goals can stay the same while each step gets easier. Tognazzini's evidence is his own earlier "law of commuting" and an argument from history, not a study, so it is a claim to weigh and not a measurement.

Whether the floor is real. The law says some complexity is irreducible. That is hard to test, because a team that cannot remove a step cannot prove nobody ever could. Many designs have removed steps that looked necessary, by redefining the task. A practitioner reading the law as a ban on simplifying would be misreading it. A safer reading is that a step removed from one place should be traced to where it went.

Where that leaves a practitioner. Treat the law as a question to ask, not as a conclusion. When someone says a change will make things simpler, ask where the work went. Then measure, with sessions, tickets, or timing, whether the new location costs less in total. If you cannot measure, say that the claim is untested.

111 min

How Tesler's Law changed since

The original wording names three parties in software: user, application developer, and platform developer. Later writers widened it.

• 1993 to 1998: other fields pick it up. Tesler's website lists Tim Andrews writing about object databases in 1993, in terms of complexity moving from the programmer to the system. By September 1998 Tognazzini was using it to explain the shift from MS-DOS to graphical interfaces to the early web.
• 2005: business processes. Sean McGrath wrote that the complexity of a business process "is like energy, it cannot be created or destroyed, it can only be moved around from one place to another". The physics comparison is his, and it is the origin of the "conservation" reading in many retellings.
• 2016: physical systems. Tesler's page quotes a New York Times Magazine summary of Raffaello D'Andrea's airport baggage concept: "Complexity is thus shifted from physical infrastructure to algorithms."

Current practice mostly matches the original meaning. One shift is worth stating. Today the phrase is often used to mean "do not make users think", which is a design preference and not what Tesler's statement says. The law does not tell you to hide complexity. It tells you to decide where it lives.

?8 questions

Questions people ask

§9 sources

Sources