When friction is the feature

Reducing steps is the closest thing our field has to a reflex. Fewer screens, fewer fields, fewer taps. It is the easiest improvement to propose in a meeting, the easiest to measure afterwards, and for most of a product it is correct.

Then you work on something where the action cannot be taken back, and the reflex starts producing damage.

I have spent a good part of my career on products where a press of a button has consequences that live outside the software: money leaves an account, a legally binding signature is applied, an identity is asserted to a government system, an order is dispatched to a warehouse that will not read your apology email. In that territory, the question stops being how few steps can we get away with, and becomes which steps are load bearing.

Undo is what makes speed safe

Most of the design advice we all absorbed was written for reversible actions. Delete an email and it goes to a folder for thirty days. Post something and you can edit it. Buy a subscription and you can cancel it tomorrow.

When undo exists, speed is almost free. A mistake costs the user a few seconds of annoyance, so the correct design is to let them move fast and fix it after. Confirmation dialogs in that world are genuinely bad design, because they tax every correct action to prevent a cheap mistake.

Take away undo and the entire calculation inverts. Now a mistake costs a bank transfer to a stranger, or a signature on the wrong contract, or a filing to a public register with your name on it. The tax on every correct action is the same as before, but what it buys is completely different.

The useful question is not “is this friction”. It is “what does a mistake here cost, and who pays it”. If the answer is that the user pays, in money or in legal exposure, and cannot get it back, then a step that forces attention is not a usability failure. It is the product doing its job.

Confirmation is mostly theatre, and there are better instruments

None of this is a defence of the confirmation dialog, which is the laziest tool in the box. “Are you sure?” is answered yes by everybody, always, including the people who are about to make the exact mistake you were worried about. It creates the feeling of a safeguard without the function of one, which is worse than nothing because it lets the team believe the problem is handled.

The instruments that actually work share one property: they require the person to demonstrate that they know what they are doing, rather than simply asserting it.

Re-entry of the consequential detail. Not the whole form again, just the part that hurts if it is wrong. Typing the last four digits of the destination account is a different cognitive act from clicking yes. It forces a person to look at the thing they are about to affect.

A summary written in the user’s terms, not the system’s. Not a field list echoing back what was typed. A sentence that says what will happen, to whom, and when, in the language a person would use to describe it to a friend. Most bad confirmations fail here: they show data, when what is needed is a claim about the future that the user can agree or disagree with.

A delay with a genuine exit. A short window where the action is scheduled rather than executed, with a visible way to stop it. This is the strongest tool available, because it converts an irreversible action into a reversible one for a while, and it costs the user nothing when they are right. It requires real work in the backend, which is why teams reach for a dialog instead.

Deliberate asymmetry. The destructive path should not look identical to the safe one. Not a red button, which people stop seeing, but a different shape of interaction: a different position, a step the muscle memory does not already own.

Speed and care are not opposites, they are different phases

The framing I find most useful is that a serious flow has two phases, and they want opposite treatment.

The composition phase is where the person assembles their intent: choosing a recipient, entering an amount, selecting which document. Every principle about speed applies here in full. Autofill, sensible defaults, remembered recipients, forgiving input formats, no unnecessary fields. Make this part as frictionless as you possibly can.

The commitment phase is the single moment where intent becomes consequence. This part should be slow, quiet, and unambiguous. One clear statement of what is about to happen. Nothing else competing for attention. No upsell, no cross sell, no newsletter checkbox, no animation that draws the eye away from the sentence that matters.

Teams get into trouble by applying one temperature to the whole flow. Either they make the entire thing ceremonial, which is exhausting and trains people to click through ceremonies, or they make the entire thing fast, and the commitment moment slides past unnoticed between two fast steps.

The count of steps was never the right metric. The distribution of attention was.

The evidence problem

There is a practical reason this argument keeps losing inside companies, and it is worth being honest about.

The benefit of removing a step shows up immediately in a funnel, attributed to the team that removed it. The cost shows up later as support volume, reversals, complaints and churn, attributed to nobody. One number moves this quarter. The other is diffuse, delayed, and lands in a different department’s budget.

If you want to win this argument you have to bring the second number into the room. Reversal rates. Support contacts per thousand completions, categorised by cause. Time between completion and first complaint. The proportion of transactions a person tried to stop after starting.

I have watched a well argued design principle lose to a conversion chart many times. I have rarely watched it lose to a chart that had the reversal rate plotted next to the completion rate. Design arguments about safety tend to fail not because they are wrong but because they are unmeasured, and unmeasured claims lose to measured ones regardless of merit.

Getting the level right

The dosage matters more than the principle, and the failure mode on the other side is real. A product that treats every action as consequential teaches people to stop reading, and then the one screen that genuinely mattered is dismissed with the same reflex as the twenty that did not. Protection you apply everywhere protects nothing.

A rough calibration I keep coming back to:

If the action is reversible by the user, make it fast and make undo obvious. No confirmation.

If it is reversible only by contacting support, add a clear summary before commitment. Support reversibility is not reversibility from the user’s point of view, it is a phone call they are dreading.

If it is not reversible at all, and the cost lands on the user, require an act of attention that a distracted person cannot perform by reflex, and give them a real exit for as long as you technically can.

If it is not reversible and the cost lands on somebody who is not even present, which happens more often than people expect in identity and public sector work, then the interface carries a responsibility to a person who never agreed to use it. That case deserves more care than any conversion target.

The part that stays with me

The people most affected by these decisions are almost never the people in the room when they are made. They are stressed, unfamiliar with the domain, using a shared device, doing this for the first and possibly only time, and they will blame themselves when it goes wrong.

Designing for that person occasionally means arguing to keep a step that makes a chart look worse. I have not always won those arguments. But the ones I lost are the ones I still think about, and none of the ones I won have ever come back to hurt anyone.