---
title: Eliminating friction
slug: friction
kind: principle
summary: Every click, screen and decision is a tax on the person doing the work. Get them to the outcome in as few steps as possible, and never make the path a secret.
problem: Software accumulates steps the way a desk accumulates paper — each one added for a reason, none of them removed. The person who does the task forty times a week pays for all of them.
principles: [friction]
status: stable
visibility: public
related:
  - title: UX Principles Guide for Building Web Software
    url: /wiki/ux-principles-for-web-software
    summary: The customer-facing version of this principle, with before-and-after demos.
---

## The rule

Count the steps between intent and outcome. Then remove some.

That sounds glib, and it is the whole discipline. Friction is not usually added
by bad decisions; it is added by *reasonable* decisions, one at a time, by people
who were not the ones repeating the task.

## The path must be obvious, not secret

The worst friction is not length, it is **sequence you have to know**. Press this
button, then that one, then this other one, in that order, or it does not work.
Nothing on the screen says so. Somebody learned it once and now trains everyone
else.

This is the *Secret sequence* failure. The cure is to make the sequence
structural — a wizard, a stepper, a disabled next button that says what is
missing — so the screen teaches the order instead of a colleague teaching it.

## Ask for less up front

The strongest friction reduction available is usually **not collecting the
information yet**. A nine-field signup that could be two fields is seven
decisions charged to someone who has not yet seen any value.

The question for every field is not *do we need this?* but *do we need this
now?* Most of the time the honest answer is: we need it when the thing it
affects actually happens, and that is a better moment to ask, because then the
question makes sense.

## Where the steps hide

- **Round trips to change one value.** Four clicks to edit a field is three
  clicks and a lost context. This is what inline editing exists to remove.
- **Confirmations on reversible actions.** A confirm dialog is a step charged to
  every user to protect against a mistake a few will make. When the action is
  reversible, undo is cheaper and safer.
- **Optional things presented as required.** A form does not distinguish, so the
  person fills everything.
- **Configuration before value.** Ten settings before the first useful action,
  chosen by someone who cannot yet know what they want.

## The tension worth naming

Friction reduction and safety pull against each other, and the resolution is not
"be careful" — it is knowing which actions are reversible. Reversible plus
low-stakes: act immediately, offer undo. Irreversible plus high-stakes: confirm,
and make the confirmation *specific* rather than a generic "are you sure".

That distinction is a decision the software makes once, per action, on purpose.
Where it is not made deliberately, every action ends up confirmed, which trains
people to click through confirmations without reading them — and then the
protection is gone anyway.