Every system has an inherent amount of complexity that cannot be reduced. It can only be moved — from the user to the system, or from the system to the user.
In the 1980s, Larry Tesler — the computer scientist who invented cut, copy, and paste — formulated an observation he called the Law of Conservation of Complexity: every application must have an irreducible amount of complexity. The question is not whether that complexity exists, but where it lives. Either the system handles it or the user handles it. There is no third option where complexity simply disappears.
Scheduling an email to arrive at the right time in someone's time zone is genuinely complex. The complexity doesn't go away if you ask the user to select from a dropdown of 40 time zones — it has simply been moved from the system to the user. The system was easier to build. The user's experience got harder. Tesler's Law names this tradeoff explicitly and forces a choice: whose job is it to deal with this complexity?
Tesler spent his career at Xerox PARC, Apple, Amazon, and Yahoo. At PARC he helped invent the modeless text editor — removing the unnecessary complexity of switching between “insert mode” and “command mode” that plagued earlier systems. At Apple he worked on Lisa and later consulted on the Macintosh, where the principle was applied systematically: the computer should do as much work as possible so the person using it doesn't have to.
His law has a specific and non-obvious implication: making an interface simpler for the user always makes the system more complex. There is no free lunch. When Google Maps auto-detects your location instead of asking you to type it, the interface got simpler. The system behind it — GPS triangulation, cell tower inference, IP geolocation — got vastly more complex. The complexity was conserved. It just moved.
“Every application must have an inherent amount of irreducible complexity. The question is only who will have to deal with it.”
— Larry Tesler
Setting a recurring calendar event requires the system to store a repeating schedule rule. That rule has real complexity: how often does the event repeat, on which days, and when does it stop? Every calendar application has to resolve these questions — the only variable is who resolves them.
The traditional approach exposes the full rule to the user: a frequency dropdown, an interval counter, a grid of day checkboxes, and an end condition picker. The alternative identifies the patterns that cover 95% of all recurring events and presents them as simple choices — the system handles the rule generation invisibly. The edge case user can still access “Custom...” for full control.
Frequency, interval, days, end condition, exceptions — the full scheduling rule exposed to a user who just wants a weekly standup.
Tap a pattern — done. Six options cover 95% of cases. The rule is generated invisibly. “Custom...” is there for the rest.
The recurrence rule still exists in the good version — it is generated and stored correctly behind the scenes. The user never has to think in terms of frequency intervals or day bitmasks. They think in patterns: “Weekly.” The system translates. This is Tesler's Law working correctly: complexity moved from user to system.
A delivery address contains several distinct pieces of structured information: a street number, a street name, an apartment or unit number, a city, a postcode, and a country. Presenting these as six separate fields delegates the parsing task to the user — they must mentally segment their address and enter each part in the correct box.
A smart address autocomplete field inverts this completely. The user types what they know — the beginning of their address — and the system uses a geocoding API to complete, parse, and fill all the sub-fields automatically. The same complexity of structuring an address is now handled by the system, which is better equipped for it than any user typing on a phone keyboard.
6 fields, all manual. The user must parse and segment their own address — work the system could do instead.
Type a few letters — system fills the rest. The parsing complexity moves from the user to the geocoding system. Tap a suggestion to see.
The apartment field remains manual in the good version — this is Tesler's Law applied with precision. The geocoding API cannot know which unit within a building the user lives in; that information exists only with the user. So that specific complexity is correctly left with them. Everything that the system can determine more reliably — the structured street, city, state, postcode, country — is handled automatically.
Early AI tools required users to write detailed, technically precise prompts to get useful output. Effective prompting — specifying tone, length, format, audience, constraints, and output structure — is genuinely complex. That complexity doesn't disappear when you give someone a blank text box. It lands on the user, who must either learn prompt engineering or accept worse results.
A well-designed AI writing interface moves that complexity into the system. Instead of asking users to articulate the precise parameters of what they want, it offers structured inputs — goal, tone, length — that translate into optimised prompts behind the scenes. The same quality of output is achievable with far less expertise from the user, because the interface has absorbed the prompt-engineering complexity.
System prompt + user prompt + 4 parameters. To get good output you need to understand tone, prompt structure, temperature, and token limits.
Choose goal, tone, describe it simply. The system translates your choices into an optimised prompt. Tap Generate.
The interface in the good example is not simpler because it does less. It is simpler because the system does more. Behind the chips and the single text area, the interface assembles a complete, well-structured system prompt, sets appropriate model parameters for the selected format, and manages the output length automatically. The user's job is to describe their goal. The system's job is everything else.
The most useful question Tesler's Law asks is: for every piece of complexity currently on screen, who is better positioned to handle it — the user or the system? If the system can detect it, infer it, calculate it, or pre-fill it, then asking the user to do it manually is not respecting their time. It is offloading engineering work onto people who came to accomplish something else.
The answer isn't always “hide it from the user.” Developers setting API endpoints, designers choosing exact colour values, and researchers configuring experimental parameters all need access to complexity that most users should never see. Tesler's Law doesn't demand simplicity across the board — it demands that complexity be positioned correctly for the people who will encounter it.
Tesler, L. (1984). The Law of Conservation of Complexity. Formulated at Xerox PARC. Tesler later worked at Apple, Amazon, and Yahoo, where he continued applying this principle to consumer product design.