The two-panel filter I have been working on has gone through four versions. Each version reduced clicks. Only the last one actually felt faster. The earlier ones felt slick and stressful at the same time, in the way that aggressive autocomplete feels, technically helpful and subtly hostile.
What I kept getting wrong was the unit. I was measuring clicks when I should have been measuring something harder to name. The distance between the moment a user decides what they want and the moment they can express it. That gap is where friction lives. Clicks are almost never where friction lives.
A click costs almost nothing. Muscle memory handles clicks. What the brain actually spends budget on is orientation, figuring out where it is, what the options mean, what will happen if it acts. That work happens before the click, not during it. And it compounds. Spend 300ms orienting on every step of a five-step flow and you have paid 1.5 seconds in cognitive overhead before you have accomplished anything. Nobody logs this as a complaint. They just say the product feels slow.
Where this goes wrong
There is a version of good design work that looks exactly like bad design work from the outside. You collapse a five-step flow into three steps. The steps are fewer. The thinking required per step is higher. The user is disoriented more often, recovers more slowly, and trusts the interface less. But the click count is down, so it ships.
I catch myself doing this. Drawing a flow with fewer nodes and assuming the diagram proves something. The diagram proves nothing about cognitive load. It only proves that I counted states.
The interface that asks you to pause is not the same as the interface that confuses you. One is respectful. The other is broken. They look the same in a Figma prototype.
The version of my filter that worked had more clicks than the wizard pattern I rejected. It had a persistent left pane showing available options and a right pane showing what had been chosen. Two panels, always visible, no steps. To add something, you click it. To remove it, you click it again. There is no confirmation, no modal, no step two. The state is always visible. The action is always the same.
The wizard I built first had four steps and required three fewer clicks to complete a selection. It also required you to hold a mental model of what you had already picked while navigating to the next step, because the previous step was gone. Users kept going back. The pattern was efficient and exhausting in equal measure. Fewer clicks, more work.
What actually reduces friction
Predictability. Not simplicity, but predictability. They overlap, but they are not the same thing. A simple interface with unpredictable state changes is still high-friction. A complex interface where every action has an obvious and reversible outcome can feel effortless.
The question I have started asking before I optimise anything is this. Does the user know what is about to happen before they act? Not after the animation confirms it. Before they commit. If the answer is yes, the click is cheap. If the answer is no, adding more clicks to give the user time to think is not always wrong.
The second question. How cheap is the recovery if they are wrong? Friction is not just the cost of doing something correctly. It is the cost of doing something incorrectly and getting back. A flow that is fast when you are right but punishing when you are wrong is a flow that makes users nervous. Nervous users slow down. They read everything twice. They hesitate at every step. You built a fast flow and they are treating it like it is fragile, because it is.
When both of those questions have good answers, when the next action is obvious and the wrong action is cheap to undo, click count stops mattering. You can have ten steps and zero friction, if every step is a confident step.
The variable we should be optimising
Most of the bad UI I have shipped looked fine in review. The flows were tight. The step counts were low. The problem only appeared when someone used it under real conditions, distracted, in the middle of something else, with a half-formed intention and no patience for ambiguity.
The variable I kept missing was quieter than click count and harder to put in a Jira ticket. It was something like this. How much does the interface demand that you trust it before it gives you feedback? High trust demand is high friction. The user is being asked to act on faith, to commit before they can see the result, to carry a mental model the interface refuses to reflect back at them.
Click reduction is a fine goal. It is just not a proxy for the right goal. The right goal is that the user should never feel like they are working harder than the task actually requires. Sometimes that means fewer clicks. More often it means fewer surprises.