Laws of UX
Tesler's Law (Conservation of Complexity)
Every process has an irreducible complexity — either the product absorbs it, or the user does.
Where it comes from
It's named after Larry Tesler, a computer scientist at Xerox PARC and later Apple, who argued in the 1980s that every application has an inherent amount of complexity that cannot be removed — only shifted between the system and the user.
Why it matters for your website
Complexity doesn't disappear — it moves. Tesler's Law says every process has a minimum complexity that has to live somewhere: better the product carries it than the user. Every step you remove from a user's task is a drop-off risk you've removed with it.
The question Tesler's Law forces is not whether a process is complex but who carries that complexity. Every bit of irreducible difficulty the product refuses to handle is handed to the user instead — and users are far less equipped, and far less patient, to carry it. A date that could be parsed from any format, but isn't, becomes the user's problem to format correctly.
This reframes 'simplicity' as a transfer, not a deletion. The simplest-feeling products are often doing the most work behind the scenes — absorbing edge cases, making smart defaults, handling the awkward parts — precisely so the person never has to. Each step of complexity you swallow is a drop-off risk you've removed from the user's path.
Wrong vs right
A form that demands a phone number in one exact format, rejecting spaces and dashes, making the user do the normalising the system could trivially do itself.
A field that accepts any reasonable format and quietly normalises it — the product absorbs the complexity, not the user.
Asking the user to calculate or look up information the system already has (a total, a tax rate, a shipping estimate) and enter it manually.
The system computing and pre-filling whatever it can, leaving the user only the genuinely irreducible decisions.
Exposing every configuration option up front 'for flexibility', pushing the burden of understanding them all onto the user.
Sensible defaults that work for most, with advanced options available but not in the way — complexity carried by the product until the user asks for it.
Understanding Tesler's Law (Conservation of Complexity)
Tesler's Law, the Conservation of Complexity, states that every process contains a baseline of complexity that cannot be designed away — it can only be moved. The design choice is therefore not how to eliminate complexity but where to put it: in the product, where engineers and designers handle it once, or in the interface, where every user has to deal with it every time.
The principle argues firmly for the product carrying the load. A team absorbing complexity pays a one-time cost and has the skills and context to do it well; a user faced with the same complexity pays it repeatedly, with less knowledge and less patience, and often abandons the task instead. Smart defaults, forgiving inputs, automatic calculations, and sensible assumptions are all ways the product shoulders difficulty so the person doesn't have to.
There's a limit, of course — some complexity is genuinely the user's to own, because it reflects a real decision only they can make. The discipline is to ruthlessly absorb the *incidental* complexity while leaving the user only the choices that are truly theirs. Tesler's Law sits close to Occam's Razor and to the broader effort to minimise cognitive load.
How Kweri checks it
Much of this is a design-judgement question — whether complexity that could live in the product has been pushed onto the user — and Kweri treats it accordingly. It can flag some concrete symptoms, such as forms that appear to demand rigid input formats or ask for information the system could derive. But whether a given step represents irreducible, user-owned complexity or avoidable, product-owned complexity is a contextual call. So Kweri surfaces likely instances of burden-shifting and prompts you to reconsider them, rather than scoring the trade-off outright.
FAQ
What is Tesler's Law?
Tesler's Law, also called the Conservation of Complexity, states that every process has an irreducible amount of complexity that can't be removed — only shifted between the product and the user. Good design makes the product carry it rather than the user.
Who was Tesler's Law named after?
Larry Tesler, a computer scientist at Xerox PARC and later Apple, who argued in the 1980s that complexity is conserved and that the burden should fall on developers rather than users. It was popularised for designers by Jon Yablonski's Laws of UX.
How do I apply Tesler's Law?
Have the product absorb as much incidental complexity as possible: accept flexible input formats, compute values automatically, use sensible defaults, and handle edge cases behind the scenes — leaving the user only the decisions that are genuinely theirs to make.
Does Tesler's Law mean removing all complexity?
No — it means complexity can't be removed, only relocated. Some complexity legitimately belongs to the user because it reflects a real choice only they can make. The goal is to absorb the avoidable complexity, not to pretend none exists.
How is Tesler's Law related to Occam's Razor?
Both push toward simplicity, but from different angles. Occam's Razor is about removing unnecessary elements; Tesler's Law is about who bears the complexity that can't be removed. Together they argue for the simplest interface that still does the job.
Related principles
Serve novices and experts at once — let experienced users take shortcuts the rest never see.
The brain has a limited processing budget — demand too much and performance collapses.
Among solutions that achieve the same goal, the one with fewest elements, steps, or assumptions is preferable — complexity that doesn't earn its place should be cut.
Attribution & sources
Identified by Larry Tesler (1980s). Catalogued from Laws of UX (Jon Yablonski).
Articulated by computer scientist Larry Tesler; popularised for designers by Jon Yablonski's Laws of UX.
See Tesler's Law (Conservation of Complexity) on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →