laws & principles
Tesler's law
Every process has a baseline of complexity that can't be designed away - it can only be moved. The question is never whether to remove it, but who carries it: the person using the product, or the people building it.
The demo
Here's the work of entering a delivery address - six pieces of it. Drag the slider to decide who handles each piece: you, or the app. Keep an eye on the total.
You fill in
The app handles
What this demo shows (text version)
Entering an address is broken into six pieces of work - splitting it into fields, looking up the street from the postcode, checking the postcode is real, fixing typos, formatting it for the courier, and knowing the country. A slider moves each piece between "you do it" and "the app does it".
However you set the slider, the bar underneath stays completely full: the amount of work is fixed. Slide everything onto the app and your form collapses to a single box - but the same six pieces still have to happen, now carried by the system instead of you. That's Tesler's law, the conservation of complexity: you can choose where the difficulty lives, but you can't make it disappear.
As you slid the work onto the app, the form shrank to almost nothing - but the bar never did. The complexity didn't vanish; you just decided the system should carry it instead of the user. That conservation is Tesler's law.
The lazy reading is "make it simple", which usually means shoving the hard part onto the user and calling the interface clean. A single elegant text box that demands a perfectly formatted input hasn't removed complexity - it's hidden the instructions and left you to fail the format on your own.
My rule: when a flow feels complicated, don't ask "how do we hide this?" - ask "who should be doing this work?" The honest answer is usually the system, even when that means more code behind the scenes. The user's effort is the expensive kind.