Key takeaways
- Reducing friction works only when you name the exact cost you will cut: mental, physical, time, or cost.
- Each cost has a different mechanism and fix, so cosmetic simplifications often trim the wrong bill.
- Measure outcomes, not proxies; “fewer steps” means nothing if the success event stays flat.
- Test paired variants that each target a different cost, then keep the one that lifts the success event with flat risk.
- Write a testable hypothesis and check before you prompt, naming the moment, event, and cost to cut.
“Reduce friction” only works when you can name the exact cost you’re cutting. There are four types of friction UX teams need to tell apart: mental, physical, time, and cost. Each has a different mechanism and a different fix. Most “simplifications” fail because they shave the wrong cost. Name it first, then choose the pattern that actually moves it.
Name the friction before you cut
The same interface can look “cleaner” and still be hard if you kept the user’s real bill intact. Mental friction is thinking and memory; physical is taps, typing, and reach; time is how long the task takes and the waits inside it; cost is money and the fear of being tricked about it. They are four of the six simplicity factors on the ability side of the Fogg Behavior Model, and they don’t substitute for each other: lowering one leaves the other three where they were. Anchor choices to mechanisms, not taste, using the principles in Persuasion Principles for Product Designers.
A generator will trim words, merge steps, or shuffle layout. It will not decide which cost blocks the outcome you care about. That is your job, with stated criteria and a testable claim. Write the hypothesis and the check now, before you prompt.
Mental friction: thinking when recall would do
Mental friction is the load of parsing, searching, recalling, and comparing in your head. Cognitive load is the processing demand; friction is the specific cost that blocks the action. Reduce it by substituting recognition for recall, revealing one decision at a time, and using defaults that reflect prior choices and are easy to audit.
Good examples are concrete labels, one job per screen, and pre-checked answers only when the user already expressed that preference. For drills and patterns, start with Mental Simplicity and train how to cut choices without hiding trade-offs.
Physical friction: taps, typing, and reach
Physical friction is motor effort: taps, typing, scrolling, target size, and pointer travel. Small tap zones, actions placed far from where the eye already is, and multi-gesture sequences raise this cost silently. Reduce it by autofilling what you already know, enlarging hit areas, collapsing redundant gestures, and keeping the primary action within reach. See patterns in Physical Simplicity.
Time friction: how long, and whether you said so
Time friction is the gap between intent and done: how long the whole task takes, plus the waits inside it, such as server lag, blocking spinners, and serialized steps. An unknown duration is its own cost, because people postpone what they cannot size. Reduce it by trimming real seconds, prefetching, parallelizing slow work, and saying upfront how long the task takes, then keeping that promise. Drills are in Time Simplicity.
Cost friction: money, and the fear of being tricked
Cost friction is the price and everything that makes it feel uncertain: fees that appear at checkout, “contact us for pricing”, renewal terms found later. Waiving a field does nothing if the blocker is, “What will this actually cost me?” Reduce it by revealing total cost and renewal terms upfront, framing value against that number, and offering a reversible path the interface actually honors. To practice this, use Cost Simplicity.
Stop removing the wrong one
Shorter is not always easier. A two-step form that drops a field but still forces users to reconcile three concepts lowered physical cost and left mental cost intact. A slick single-tap flow that hides fees reduces physical friction and spikes cost friction, which is worse.
If you cannot name which cost you cut, you did not simplify; you rearranged the bill.
Misclassification is common because proxy metrics reward the visible. Teams celebrate “fewer steps” or “less text” even when the success event stays flat.
Test which friction you have
Name the moment you want and the single success event that proves that moment tomorrow. Ask the user to narrate the next click and capture their first hesitation; translate that sentence into a cost. “I’m not sure what this costs” is cost; “where do I type that?” is physical; “I’ll do it later” is usually time; “which one do I pick?” is mental. Build paired variants that each cut a different cost; ship behind flags. Read next-day lift on the success event and the bad-event rate; keep the cut that lifts with flat risk.
Set a flip threshold before you generate: “Activation = first successful X within 24 hours,” or “Trust = opt-in to Y after reading Z.” Evaluate variants by whether they reduce the named cost at that moment, not by polish. If nothing moves, you misnamed the cost.
Train the cut you mean
Your edge is choosing the mechanism, then writing the constraint and check before you prompt. Start with the cost your hesitation test named, not the one that is easiest to ship. The four simplicities, with the patterns and the traps for each, are in the Quest skill library.
You are a UX experiment lead coaching a product designer to cut the right friction. Ask me for context about [describe the flow or decision], [name the moment you want], and [define the single success event and any bad-event]. Using the four types of friction (mental, physical, time, cost), diagnose the likely blocker and state why. Produce: 1) a testable hypothesis that names the cost to cut and the expected next-day lift on the success event with flat risk, 2) two variant briefs, each cutting a different cost with concrete patterns, 3) an interview script to capture the first hesitation and translate it into a cost, 4) an instrumentation plan, flip threshold, and rollback criteria, 5) a next-day read plan. Constrain solutions to substitute recognition for recall when mental, reduce taps, typing, and precision when physical, trim real seconds and state the duration upfront when time, and reveal total price, renewal terms, and a reversible path when cost.
Frequently asked questions
What are the four types of friction in UX and what does each one mean?
Mental friction is the thinking and memory load to parse, recall, and compare; physical friction is motor effort like taps, typing, reach, and precision; time friction is how long the task takes plus the waits inside it; cost friction is the price and the fear of being tricked about it, such as hidden fees or renewal terms. Each has a different mechanism, so you cut the specific bill, not just shorten steps.
How do I figure out which friction type is blocking my users?
Name the target moment and one success event due within 24 hours, then run a quick think-aloud: “Narrate your next click.” Capture the first hesitation verbatim and map it to mental, physical, time, or cost: “which one do I pick?” is mental, “what will this cost me?” is cost. Build paired variants that each cut a different cost, ship behind flags, and read next-day lift plus bad-event rate.
When should I prioritize mental friction over physical friction?
Choose mental first when users must recall facts, reconcile concepts, decode labels, or compare options. Shift to physical when the blocker is movement: tiny targets, long travel, hand switching, typing, or precision taps. Start with patterns from Mental Simplicity, then apply Physical Simplicity if motor effort, not understanding, is the bottleneck.
What metrics prove I cut the right friction?
Define a flip threshold before you generate: the single success event within a window (e.g., activation in 24 hours). Track next-day lift on that event and a paired bad-event rate such as errors, cancellations, or support pings. Ignore proxy wins like fewer steps or less text unless the success event moves. Keep the lift with flat or lower risk.
What patterns reduce time friction without faking speed?
Trim real seconds, prefetch predictable data, and parallelize slow work so intent keeps flowing. Say upfront how long the task takes and keep that promise; show honest progress and keep steps cancellable. In the Fogg Behavior Model time is an ability factor, and Time Simplicity has the drills.
