The "zero-friction design" mantra has shaped a generation of product decisions. One tap, one click, one swipe. Interfaces so smooth that users arrive at their destination before deciding whether they actually wanted to go. And that's the problem: some destinations shouldn't be reached quite so fast.
The obsession with removing friction comes from a legitimate place. Twenty-step forms, nightmarish checkout flows, content-blocking pop-ups — that kind of friction genuinely kills conversion and destroys trust. Nobody defends it. But the industry has overgeneralised: from "remove unnecessary friction" we've arrived at "remove all friction," and that leap carries real consequences for the people using our products.
A growing trend is emerging in fintech, health, and wellness products: designers deliberately introducing reversible resistance at the precise moments when users are about to act against their own stated goals. Not to retain them. To protect them.
Badly designed friction is bureaucracy disguised as flow: it penalises the user without benefiting them.
Well-designed friction is a cognitive pause: it activates deliberation exactly when automaticity was about to take over.
The difference isn't how much resistance you add, but at which point in the user's JTBD you introduce it — and how reversible you make it.
Flow: The Problem With Making Everything Too Easy
When we design for maximum flow, we optimise for execution. The user arrives, acts, leaves. If the product does its job, that action repeats. But there are product categories where repetition isn't the user's goal, even if it happens to be the business's.
Retail investment platforms are the most documented case. Those that maximised gamification and friction removal — confetti on purchase, trending asset lists, swipe-to-buy — saw activity increases that didn't translate into better outcomes for investors. The data is uncomfortable: greater ease of execution correlates with more impulsive trades, not better decisions. A swipe that takes 0.3 seconds leaves no room for the question "should I actually do this?"
Frictionless design assumes the user always knows what they want at the moment of action. But behavioural research has spent decades telling us otherwise: under stress, fatigue, or impulsivity, the brain's automatic system takes over. And that system doesn't account for the long-term goals the user told us they had when they signed up.
Designing only for present intent is betraying the future goal the user entrusted to you at onboarding.
This connects directly to the Jobs-to-be-Done framework: the "job" the user hired the product for isn't always "execute this action right now." Sometimes it's "help me not make this decision without thinking." The same mistake we make when adding AI features that serve the product rather than the user applies here: optimising for execution while ignoring the other half of the contract.
Architecture: How to Design Friction That Actually Helps
Intentional friction isn't about placing random obstacles. It has a precise architecture with three conditions that must be met for it to work without destroying the experience.
Condition 1: Contextual activation, not blanket policy
Friction must appear at the specific moment a user is about to act against their stated goal — not as a universal product policy. A user withdrawing savings to pay an unexpected bill shouldn't face the same resistance as someone emptying their emergency fund after a volatile week in the markets. Context is everything.
This requires the product to know the user's declared objective — what in JTBD terms we'd call the "primary job" — and to have signals for detecting when the current action is in tension with that objective. It's not trivial to build, but it's exactly the kind of logic layer that justifies adding intelligence to a product.
Condition 2: Visible and immediate reversibility
Friction that paralyses isn't friction — it's a barrier. The operational difference is reversibility. Users must be able to bypass the resistance with one additional clear step, without hidden penalties and without the system recording it as a failure. "Are you sure? Your goal was €X by December. [Yes, continue] [Wait a week]" is very different from making the withdrawal button disappear for 72 hours.
Reversibility also protects the product from becoming paternalistic. If users can easily override the friction, responsibility remains theirs. The design has only ensured the decision is conscious, not that it's the one the designer considers correct.
Condition 3: Honest explanation in the moment
Friction without context is opacity. Users need to understand why the product is adding that extra step — not in the terms and conditions, not in a help screen, but right there, in two lines. "We're asking you to pause because in the past three days you've already withdrawn €X and your monthly goal will suffer" is an explanation that builds trust. "This is for your security" is an excuse.
This condition has an important secondary benefit: transparency about intent means the user who genuinely wants to continue doesn't feel judged. Explained friction is respect, not a sermon.
Context: Where It Makes Sense — and Where It Doesn't
Intentional friction makes real sense in products where there's a structural tension between the user's short-term and long-term goals: personal finance, health and wellness, productivity, content consumption, learning. These categories share something: the user arrives with a future self in mind and sometimes takes decisions that sabotage that self. A product that recognises and elegantly manages that tension builds loyalty that purely frictionless products can't buy.
It makes no sense in purely transactional products where efficiency is the only value: booking a flight, paying a bill, sending a signed document. Added friction here would be paternalism without justification. The same product intelligence that enables intentional friction needs to know when not to apply it.
There's an interesting grey area in premium e-commerce and subscription content platforms. Here, intentional friction could reinforce perceived value — a slightly slower selection process signals care — but the risk of it reading as mere slowness rather than deliberation is high. Implementation precision matters more here than anywhere else.
The question isn't whether your product should have friction. It's whether you know the user's JTBD well enough to identify the exact moments where resistance works in their favour.
Implementation: From Theory to the Product in Front of You
Talking about intentional friction in the abstract is straightforward. Landing it in a real product requires a process that should happen before touching a single pixel.
The first step is tension mapping. In a JTBD workshop, we identify moments in the flow where there's a gap between the job declared by the user in onboarding or qualitative research and the action the product makes easy at that point. Not every product has these tensions. Those that do usually have more than their teams recognise.
The second is impact classification. Not every tension justifies adding friction. We prioritise along two axes: the magnitude of potential harm to the user if they act without deliberating, and the frequency with which that moment occurs in real usage. High-frequency, high-impact moments are the candidates. Low-frequency, low-impact ones are not.
The third is prototyping the language before the visual design. Intentional friction lives or dies in the copy. Tone, length, option structure — all of it determines whether the user feels the product is on their side or lecturing them. When research stays trapped in a static deliverable instead of feeding real-time design decisions, the insights exist but never generate actionable learning — and friction design without real user knowledge is guesswork.
For teams that have spent years under the "maximum flow" doctrine, this shift is uncomfortable. Some metrics will dip in the short term — immediate action rate, possibly raw engagement — while the metrics that improve are slower and harder to attribute: six-month retention, NPS, outcome satisfaction. The internal argument is hard to win when the team only looks at the weekly funnel.
The right conversation isn't "do we add friction or not?" It's "what promise did we make this user at signup, and are we designing to help them keep it?" A product can work perfectly from a technical standpoint and still be failing its users in every session — simply because it's optimising for the wrong metric at the wrong moment.
If your product has that tension between goals and you haven't mapped it yet, it's a conversation worth half a day of workshop before the next design iteration. At Room 714 we run it regularly as the starting point for experience audits: not to add friction as a principle, but to find the two or three moments where your current design is actively working against the very user it claims to serve.
