{"slug":"friction","meta":{"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."}]},"body":"## The rule\n\nCount the steps between intent and outcome. Then remove some.\n\nThat sounds glib, and it is the whole discipline. Friction is not usually added\nby bad decisions; it is added by *reasonable* decisions, one at a time, by people\nwho were not the ones repeating the task.\n\n## The path must be obvious, not secret\n\nThe worst friction is not length, it is **sequence you have to know**. Press this\nbutton, then that one, then this other one, in that order, or it does not work.\nNothing on the screen says so. Somebody learned it once and now trains everyone\nelse.\n\nThis is the *Secret sequence* failure. The cure is to make the sequence\nstructural — a wizard, a stepper, a disabled next button that says what is\nmissing — so the screen teaches the order instead of a colleague teaching it.\n\n## Ask for less up front\n\nThe strongest friction reduction available is usually **not collecting the\ninformation yet**. A nine-field signup that could be two fields is seven\ndecisions charged to someone who has not yet seen any value.\n\nThe question for every field is not *do we need this?* but *do we need this\nnow?* Most of the time the honest answer is: we need it when the thing it\naffects actually happens, and that is a better moment to ask, because then the\nquestion makes sense.\n\n## Where the steps hide\n\n- **Round trips to change one value.** Four clicks to edit a field is three\n  clicks and a lost context. This is what inline editing exists to remove.\n- **Confirmations on reversible actions.** A confirm dialog is a step charged to\n  every user to protect against a mistake a few will make. When the action is\n  reversible, undo is cheaper and safer.\n- **Optional things presented as required.** A form does not distinguish, so the\n  person fills everything.\n- **Configuration before value.** Ten settings before the first useful action,\n  chosen by someone who cannot yet know what they want.\n\n## The tension worth naming\n\nFriction reduction and safety pull against each other, and the resolution is not\n\"be careful\" — it is knowing which actions are reversible. Reversible plus\nlow-stakes: act immediately, offer undo. Irreversible plus high-stakes: confirm,\nand make the confirmation *specific* rather than a generic \"are you sure\".\n\nThat distinction is a decision the software makes once, per action, on purpose.\nWhere it is not made deliberately, every action ends up confirmed, which trains\npeople to click through confirmations without reading them — and then the\nprotection is gone anyway.\n"}