Tesler's Law: The Conservation of Complexity

UI/UX

There is a law of interface design that sounds almost philosophical but has extremely practical consequences: complexity cannot be destroyed, only moved. Tesler’s Law, also called the conservation of complexity, holds that every process has an inherent, irreducible amount of complexity, and the only real question is who deals with it, the person using the product or the system behind it. You cannot wish the complexity away, because it is intrinsic to the task. But you can decide where it lives. Great products absorb as much of that complexity as possible into the system, so the person experiences something simple. Poor ones push it onto the user, who then has to do the hard, fiddly work the software could have done for them. Understanding this changes how you think about simplicity: your job is not to pretend complexity does not exist, but to make sure your users are not the ones carrying it.

What the law actually means

Tesler’s Law came from the observation that in any given process there is a certain amount of complexity that is simply part of the task and cannot be removed without changing the task itself. Consider something as ordinary as entering an address, scheduling around time zones, or applying a discount with conditions. Each of these has irreducible complexity, the rules, the edge cases, the exceptions that genuinely exist in the world. That complexity has to be handled somewhere. Either the system handles it, quietly and cleverly, so the person just does the simple thing, or the system ignores it and the person is left to handle it themselves, entering data in exactly the right format, doing the mental arithmetic, remembering the exceptions. The complexity is conserved either way; the design decision is who bears it.

The insight that makes this a law rather than an observation is that the complexity is genuinely fixed. Teams sometimes imagine they can simplify a product by just removing complexity, and then discover they have only hidden it or shoved it onto the user. Real simplification is not making the complexity vanish, which is impossible, it is relocating it from the person to the system. That reframing is the whole practical value of Tesler’s Law: it tells you that simplicity for the user is always paid for by effort in the system, and that this is a trade worth making almost every time.

Who should absorb the complexity

The guiding principle is that the system, and the team building it, should absorb as much of the inherent complexity as possible, so the user’s experience is as simple as it can be. This is not the easy path for the builder, because absorbing complexity into the system means more thought, more careful engineering, more handling of edge cases behind the scenes. It is far easier, for the team, to expose the complexity and make the user deal with it, which is exactly why so many products do. But every bit of complexity you push onto the user is effort, confusion, and opportunity for error that you have chosen not to handle yourself. The professional stance is to take that burden on, because your team handles the complexity once, in one place, while every user would otherwise have to handle it over and over.

A simple example makes the trade vivid. When a form asks a person to enter a date in a rigid, specific format and rejects anything else, it has pushed the complexity of formatting onto the user. When a form accepts a date however the person naturally writes it and does the work of interpreting it, the system has absorbed that complexity instead. The task, recording a valid date, is equally complex in both cases. The difference is entirely who does the work, and the second approach is better precisely because the system carried the load the user would otherwise have carried. Multiply that single decision across every field, every step, every interaction in a product, and it is the difference between something that feels effortless and something that feels like a chore.

The line you should not cross

There is an important limit to this, because the conservation of complexity has a floor. You should absorb all the complexity you legitimately can, but some irreducible core genuinely belongs with the user, because it reflects a real decision only they can make. If you try to eliminate that too, by guessing on the person’s behalf about something only they can truly decide, you do not simplify, you take away necessary control and often get it wrong. The art is to absorb all the incidental, mechanical, formatting, rule-handling complexity, the work the system can do better, while leaving the person the genuine choices that are rightfully theirs. Over-absorbing complexity, by hiding real decisions or removing meaningful control, is its own failure, one that connects to the user control and freedom principle in Nielsen’s heuristics: people need to stay in charge of the decisions that matter to them. The goal is not to make every decision for the user, it is to spare them every bit of effort that is not a real decision.

How this shapes design decisions

Tesler’s Law gives you a lens to apply to any interface: for each thing you are asking the user to do, ask whether that effort is genuinely theirs to expend or whether the system could absorb it. Whenever the answer is that the system could handle it, that is where you should invest, because you are converting user effort into system effort, which is almost always the right trade. This is the deeper principle beneath many familiar UX practices. Smart defaults absorb the complexity of a decision by making a good choice the person can accept without thinking, which is why they are so central to reducing cognitive load. Progressive disclosure absorbs the complexity of a dense interface by revealing depth only as needed, the discipline of progressive disclosure done right. Forgiving inputs, sensible automation, and intelligent handling of edge cases are all, at heart, the system absorbing complexity so the user does not have to.

Seen this way, a great deal of good design is really the same move applied again and again: find the complexity, and move it off the user and into the system. The products that feel magically simple are almost never simple underneath, they are usually doing an enormous amount of hidden work to spare the person effort, which is Tesler’s Law honoured deliberately. The products that feel needlessly hard are usually not more complex in reality, they have just pushed their complexity outward onto the people using them.

Simplicity is earned, not found

The most important shift Tesler’s Law produces is in how you understand simplicity itself. Simplicity for the user is not something you find by removing things until the product looks clean, it is something you earn by having the system take on work the user would otherwise do. A genuinely simple experience usually sits on top of a great deal of invisible complexity that someone chose to handle so the person would not have to. This is why real simplicity is expensive and rare: it requires the team to do the hard part instead of exporting it. When you see a product that feels effortless, you are usually looking at a team that absorbed the complexity conscientiously, and when you see one that feels needlessly hard, you are usually looking at one that pushed its complexity onto its users because that was easier for the builders. Tesler’s Law tells you which kind of product you are building, and it is decided by who you let carry the weight.

A worked example: two checkouts

Picture two checkouts selling the same thing. The first asks the person to enter their card number in exactly the right groupings, their expiry in a specific format, their address split across rigidly labelled fields in a fixed order, and rejects anything that does not match, sending them back to hunt for the offending character. Every piece of formatting complexity in the transaction has been pushed onto the customer, who now does careful, error-prone clerical work at the exact moment you most want them to feel confident and unhindered. The checkout technically functions, but it functions by making the person absorb the complexity.

The second checkout accepts the card number however it is typed and formats it itself, reads the expiry in whatever reasonable form it arrives, accepts the address as the person naturally writes it and does the work of parsing it, and quietly handles the edge cases behind the scenes. The transaction is exactly as complex as before, the same rules and validations still exist, but the system has absorbed that complexity so the customer experiences something almost effortless. The second checkout will convert better, not because it removed any complexity, which is impossible, but because it moved that complexity off the person and onto itself. This is Tesler’s Law deciding a real business outcome, and it is decided entirely by who the team chose to make carry the load.

Where teams get this wrong

The most common failure is the path of least resistance for the builder: exposing complexity because handling it is hard. It is genuinely easier to demand rigid input, surface every option, and make the user conform to the system’s internal model than it is to build software that accommodates how people actually behave. So teams under time pressure, again and again, quietly export their complexity to users, each decision defensible in isolation and collectively producing a product that feels like work to use. The tell is a product full of strict formats, unexplained requirements, and options that exist because they were easy to expose rather than because the user needed them.

A subtler failure is mistaking exposing complexity for offering power. Teams sometimes justify a fiddly, demanding interface as giving users control, when in fact they have simply declined to do the work of absorbing complexity and dressed that decision up as flexibility. Real power-user design still absorbs the incidental complexity and reserves user effort for genuine decisions; it does not make people do mechanical work the system could have done. The distinction, again, is between the complexity that reflects a real choice, which belongs with the user, and the complexity that is merely mechanical, which belongs with the system. Confusing the two is how products end up demanding a great deal of effort while delivering little real control.

Absorbing complexity with AI

The conservation of complexity has taken on new force with AI, because AI dramatically expands what the system can absorb on the user’s behalf. A great deal of complexity that once genuinely had to fall on the user, interpreting messy input, making sense of ambiguous requests, handling situations too varied to script, can increasingly be absorbed by intelligent systems, which means the line of what the system can reasonably take on has moved. Tasks that used to require the user to conform to a rigid structure can now often accept natural, human input because the system is capable of interpreting it, which is Tesler’s Law with a larger share of the complexity newly movable to the system side.

This is an opportunity and a responsibility at once. The opportunity is to make products far simpler for users by having AI absorb complexity that was previously unavoidable for them. The responsibility is to do it well, because AI that absorbs complexity badly, by guessing wrong on things that mattered, creates a new problem in place of the old one. The principle still holds: absorb the incidental complexity the system can genuinely handle, now including much more than before, while leaving the user in control of the real decisions. Used this way, AI is essentially a bigger sponge for exactly the kind of complexity Tesler’s Law says you should be moving off the user, and the teams that use it that way will build products that feel dramatically simpler than what came before.

The cost and the payoff

It would be dishonest to pretend absorbing complexity is free, because it is not, and understanding the trade is part of applying the law well. Building a system that accommodates how people actually behave, handles the edge cases, and does the fiddly work invisibly is genuinely harder and more expensive for the team than exposing that complexity and letting users cope. That cost is exactly why so many products do not do it. But the payoff is decisive and lasting: the team pays the cost once, in one place, while the alternative charges every user a small tax on every interaction, forever. Multiplied across all your users and all their interactions, the total effort saved by the system absorbing complexity vastly exceeds the effort it cost the team to absorb it.

This is why absorbing complexity is almost always the right long-term trade even when it is the harder short-term one, and why the products that win on experience are usually the ones whose teams were willing to do the hard part. Seen clearly, Tesler’s Law is not only a design principle but an argument about where effort should live: with the few who build the product, not the many who use it. A team that internalises that will consistently choose to carry the weight, and their users will feel the difference in every interaction without ever knowing why.

Spotting exported complexity in your own product

The practical skill Tesler’s Law gives you is the ability to notice, throughout your own product, the places where you have quietly exported complexity to users, because these are usually invisible to the team that built them. A few patterns reliably reveal it. Look for anywhere you demand a specific input format and reject anything else, because that is formatting complexity you pushed onto the user instead of interpreting yourself. Look for anywhere you ask people to provide information you could have determined on your own, because that is work the system declined to do. Look for anywhere users routinely make the same mistake, because a common error is usually a sign that the interface pushed a burden onto them that they cannot reliably carry, and the fix is to absorb it rather than to blame them.

Look, too, for places where people have to hold information in their head from one step to another, or repeat something they already told you, or do mental arithmetic the system could do for them, because each of these is the system leaning on the user to carry complexity it could hold itself. Every one of these is an opportunity to move complexity off the person and into the product, and the cumulative effect of finding and fixing many of them is a product that feels dramatically simpler even though its underlying task never changed. The habit worth building is to walk through your key flows asking, at each step, whether the effort you are demanding of the user is a genuine decision only they can make or mechanical work the system could absorb, and to treat every instance of the latter as a defect to be fixed.

This lens also protects you from a subtle trap: adding features to help users cope with complexity you should have absorbed instead. When a product is hard to use, the instinct is often to add help, tutorials, tooltips, and documentation, all of which are ways of assisting the user in bearing complexity rather than removing that burden. Sometimes that is genuinely necessary, but often the better move is to absorb the complexity so the help is not needed at all, because the simplest interface is the one that never required an explanation. Tesler’s Law pushes you to ask, before building the tutorial, whether the thing needing a tutorial could simply be made to not need one, which is almost always the stronger answer.

The empathy behind the law

Underneath the mechanics, Tesler’s Law is really a statement about empathy, and holding it that way keeps you honest. Every time you decide who absorbs a piece of complexity, you are deciding whose life to make easier, your team’s or your user’s, and defaulting to the user is defaulting to your own convenience at their expense. The teams that build genuinely good products are the ones that take on discomfort so their users do not have to, treating the extra effort of absorbing complexity as simply part of the job rather than as an optional nicety. That posture, a willingness to carry the weight on behalf of the people you serve, is what separates products that feel considerate from products that feel indifferent, and users feel the difference even when they cannot name its source. Seen this way, applying Tesler’s Law well is less a technique than a value: it is the decision to make your problems your own rather than passing them to the people you are meant to be helping.

The takeaway

Tesler’s Law says every process has an irreducible amount of complexity that can only be moved, not removed, so the real question is who absorbs it, the user or the system. Good design absorbs as much of that complexity as possible into the system, sparing the person every bit of effort that is not a genuine decision, while still leaving them in control of the choices that are truly theirs. Simplicity for the user is not found by hiding complexity, it is earned by having the system carry it, which is harder for the team and almost always worth it. Look at what you ask users to do, move every avoidable bit of that effort into the system, and you build the kind of product that feels effortless because someone made sure it was.

If you want help taking complexity off your users and into a product that feels effortless, we would love to help.