Every Simplification You Ship to Users Becomes Complexity Someone Inside Has to Own

In our app a person taps once to move value. That is the whole interaction. Behind the tap, our systems are choosing which chain the assets currently sit on, whether they need to cross to another one, which route to take, what the fee will be, what to do if the route stalls halfway, and how to present any of that if it goes wrong.

None of that reaches the person holding the phone. That was the design goal, and I would make the same call again.

But the work did not disappear when we hid it. It moved. It moved from the user, who used to do it manually and badly, onto us, where it now lives permanently. I have started treating that as a law rather than a side effect, and it has changed how I approve things.

Complexity is conserved

Every simplification is a transfer. You are not deleting difficulty, you are deciding who carries it, and the two candidates are your users and your own systems. Choosing your systems is usually correct, because your team can carry it once for everyone rather than each customer carrying it alone. That is most of what good product work is.

The failure is in the accounting. Organisations budget the visible half of that transfer, which is the interface, and treat the invisible half as an implementation detail. It is not a detail. It is a permanent operating liability that grows with usage, and it lands on a team that frequently was not in the room when the simplification was approved.

Ask any engineer who has inherited a system whose main selling point is that it makes something look easy.

The failure modes you inherit

When we made multiple chains invisible, we also inherited every reason a cross-chain movement can behave badly. Something can be slow rather than broken. A route can succeed on one side and stall on the other. Conditions can change between the moment we quote and the moment we execute.

Our user cannot see any of that, so from where they sit there is exactly one thing that failed: us. That is not unfair. It is the arrangement we chose when we removed their visibility, and I would rather own it than push the detail back onto a person who came to us specifically so they would not have to think about it.

What it means practically is that the support and reliability burden of an abstraction is not proportional to how hard it was to build. It is proportional to how many distinct ways the thing underneath can misbehave, which is a completely different number and almost never the one in the plan.

The bug report gets worse as the interface gets better

Here is the effect I did not anticipate early enough. The better your abstraction, the less useful your users become at describing problems in it.

When people operated the machinery themselves, they could tell you which step failed, because they performed the steps. Once you hide the steps, the most detailed report anyone can honestly give you is that it did not work. They are not being unhelpful. You removed the vocabulary they would have needed, on purpose.

The consequence is that observability stops being an engineering nicety and becomes the thing that makes the product supportable at all. If you cannot reconstruct what your own system decided and why, without asking the user, you have shipped an abstraction you cannot maintain. That work has to be funded at the same time as the simplification, not in the following quarter, because the following quarter is when the tickets arrive.

The question I now ask before approving one

Not whether we can make something simpler. We almost always can. The questions are narrower.

Who owns the surface this creates, and have they agreed to it? An abstraction with no named owner does not stay simple. It rots, quietly, until it fails at scale.

Can we see inside it without the user's help? If not, we are not ready to ship it, however good the demo is.

What is the failure story? Not the happy path, which everyone has thought about. What we show a person when the thing behind the curtain is having a bad day, and whether that message respects them enough to say what actually happened.

What we deliberately refuse to hide

There is a line, and it is not about difficulty. It is about consequence.

We will hide a route, a fee calculation, a chain, a piece of plumbing, anything where the detail is our problem rather than the user's. We will not hide the fact that an action cannot be undone. Irreversibility is not an implementation detail, it is the single most important thing a person can know before they act, and abstracting it away is how you build a product that feels effortless right up to the moment it costs somebody something permanent.

That distinction is the useful test. Simplify the machinery. Never simplify the consequence.

Most technology leadership conversations about user experience stop at whether something can be made easier. The more expensive question is whether the organisation is prepared to carry what the easiness costs, for as long as the product exists, on a team that has to be named before the work is approved rather than after.