What you'll understand by the end of this lesson
- Why some complexity can never be removed from a system — only relocated
- How over-simplified interfaces create confusion rather than ease
- Where the balance sits between reducing friction and giving users enough control
- How Tesler's Law applies to forms, checkouts, and onboarding flows
The principle in plain English
Tesler's Law — also called the Law of Conservation of Complexity — was proposed by Larry Tesler, a computer scientist who worked at Xerox PARC and later at Apple. His observation was simple and surprising:
Every system has a certain amount of complexity that cannot be removed. It can be moved — from the product to the user, or from the user to the product — but it cannot be eliminated.
If you simplify the interface too aggressively, you don't remove the complexity. You transfer it. The user is now the one who has to hold the complexity in their head, figure it out mid-task, or ask for help. What looked like a simpler experience on the surface is actually a harder one in practice.
The designer's job isn't to make things simple. It's to carry as much complexity as possible on behalf of the user — without hiding information they genuinely need.
A simple example
A thermostat with a single dial — turn it up to get warmer, turn it down to get cooler — is simple. But it's also imprecise. The user has to experiment to find the right temperature. They're carrying the complexity of calibration.
A thermostat that shows the current room temperature, the target temperature, and lets you set specific values is more complex visually. But it transfers that complexity to the device. The user knows exactly what's happening and can make a confident decision.
Making the interface simpler (one dial) didn't make the task simpler. It made it more opaque.
How Tesler's Law breaks conversion flows
Over-simplified checkout flows
A checkout flow reduced to the minimum number of fields sometimes removes fields the user actually needed. A form that asks only for "Name" instead of "First name" and "Last name" seems simpler — but when the system then formats the name incorrectly on the invoice or confirmation, the user's problem has simply moved from filling in the form to fixing the error after the fact.
A one-page checkout that combines payment, billing, and delivery in a single scrollable view looks minimal. But if users can't tell where they are in the process, whether their address has been saved, or what happens when they click the button, the perceived simplicity creates real confusion.
The complexity of a purchase hasn't changed. The buyer still has to specify what they want, where to send it, and how to pay. A checkout that hides the structure of that process doesn't remove those decisions — it just makes them harder to follow.
Forms with too few fields
A lead capture form reduced to one field — "Enter your email to get started" — has very low friction at the point of submission. But if the sales process immediately requires the information you didn't capture (company name, role, use case), you're not saving the user from filling in fields. You're moving those fields into a follow-up email, a sales call, or a manual qualification step.
The information was always going to be needed. The form's apparent simplicity transferred the collection step to a different, more costly channel.
The right question isn't "how few fields can we get away with?" It's "which fields must be filled in before the user can get value — and which ones are we capturing for our own convenience?" Fields that exist only for the company's internal systems belong after the conversion event, not before it. Fields that the user needs in order to receive what they came for belong in the flow.
Onboarding flows that hide necessary decisions
A SaaS onboarding that skips all configuration choices in favour of sensible defaults is fast. But if those defaults don't match the user's context, they'll arrive at a product that doesn't feel set up for them — and they'll churn before discovering the settings they needed.
The product has carried the complexity of configuration on behalf of the user during setup. But the user has to carry it again later, in a less guided environment, when they're more likely to give up.
Good onboarding finds the irreducible decisions — the ones only the user can answer — and asks for those, and only those. Everything that can be inferred or set to a sensible default should be handled by the product.
One of the most common Tesler's Law mistakes is when simplification work removes complexity from the screen without removing it from the system. Hiding options in a submenu, collapsing fields behind a toggle, or deferring configuration to "settings" doesn't simplify the experience — it obscures it. Users who can't find what they need feel lost, not helped. Complexity needs to be genuinely carried by the product, not just moved out of sight.
The balance: enough control to feel confident
There's a second failure mode of Tesler's Law: adding complexity that serves the system, not the user.
Multi-step checkout flows that force the user to confirm details across three separate screens before payment. Onboarding surveys with 15 questions "to personalise your experience" before the user has seen what the product does. Settings pages with 200 options, most of which exist because an engineer needed them, not because a user ever asked.
The balance point is: carry as much complexity as possible in the product — but always leave the user with enough control to feel confident. A user who has no visibility into what's happening doesn't feel unburdened. They feel uncertain.
Progress indicators, clear confirmation steps, visible states, and reversible actions are all ways to give users control without adding unnecessary complexity. They say: "we're handling this, and you can see that we are."
The CRO audit
Look at your forms, checkouts, and onboarding flows and ask:
1. Is the complexity reduced — or just hidden?
If you've removed steps or fields, trace what happened to the information or decisions those steps contained. If they've moved to a follow-up email, a manual process, or a settings page the user will struggle to find — you haven't simplified anything.
2. Are there fields or steps that exist only for internal convenience?
Remove them from the main flow. Move them to after the conversion event. Never make users carry your operational complexity.
3. Does the user have enough visibility to feel confident?
After each step of a checkout or onboarding, does the user know what's been saved, what comes next, and what they can change? If not, add progress indicators and confirmation states — even if it adds more "steps" to the flow.
A team removes the 'Company name' field from their lead capture form to reduce friction. Later, the sales team has to email every lead to collect the company name before qualifying them. What has happened through the lens of Tesler's Law?
You've seen how complexity can be moved but not eliminated. Now — what about getting users to start an action in the first place? There's a principle about why the first step is the hardest, and how making it tiny changes everything.