Friction is systemic, not accidental

No one plans a painful experience. It gets assembled: a form field added for a legacy system, a policy written for an edge case, an assumption that customers know what insiders know. Each choice is defensible on its own; together they compound into an experience that fights the customer. Because friction is built in by decisions, it can be mapped like any other property of the system. Layering the four task dimensions over your worst customer pain points produces a friction map: a diagnostic showing where the pain lives and what kind of pain it is, so teams can intervene at the root cause instead of the symptom.

Why it matters to the business

The systemic nature of friction explains why companies misjudge their own experience so badly. Bain's 'Closing the Delivery Gap' study found 80% of companies believed they delivered a superior experience; only 8% of their customers agreed. Insiders cannot feel friction they designed in, because they carry the missing knowledge and know all the workarounds. The payoff for fixing the system is real: McKinsey reports journey improvements lift revenue 10-15% while cutting cost-to-serve 15-20%. Friction removal is one of the few levers that moves growth and cost in the same direction.

How to use it

• Build a friction map: plot your top customer pain points against the type of friction causing each (manual, cognitive, error, knowledge).
• For every pain point, trace the design decision or inherited constraint that created it, write it down, and name an owner.
• Ban 'user error' as a closing category in support and QA; every recurring user error gets a root-cause review.
• Redirect budget from training, tooltips, and help content toward removing the need for them.
• Track friction-removal wins by their effect on support volume, abandonment, and repeat contacts.

Where teams get it wrong

Teams treat friction as a customer education problem. They fund onboarding videos, tooltips, and thicker documentation while the underlying design stays untouched. Explaining the maze is cheaper this quarter than removing the walls, but customers keep hitting the walls, and every patch adds one more thing to maintain.

Ask your team

• What share of our support and onboarding content exists to explain things the product could simply do?
• When a customer struggles, is our default response to fix the flow or to explain the flow?
• Which inherited constraint, such as a legacy system or an old policy, creates the most customer friction today, and what would removing it cost versus what it costs us now?

Friction is designed in, one assumption at a time. It can be designed out the same way.