interaction design
Feedforward
What is feedforward in UX?
Feedforward is information that tells you what will happen before you act, so you can predict the result of a control without trying it. Where feedback confirms what just happened, feedforward previews what's about to - a label, a hint, a hover preview, a disabled-until-valid state - letting people act with confidence instead of guessing and hoping.
Also known as: feedforward, feed-forward
Prefer to watch?
Watch the recap 1:00
The demo
A button that deletes things. First with no warning of what it'll do - then with the consequence shown up front. Use each one and notice which lets you act with confidence.
What this demo shows (text version)
A delete control is shown two ways. Without feedforward it's a bare "Delete" button - you click it and only afterward discover it removed three items, including a draft you wanted to keep, so feedback is left to clean up a mistake you couldn't foresee. With feedforward the button and its surroundings tell you the consequence before you commit - "Delete 3 items, including your draft" - so you know exactly what will happen and can choose correctly the first time.
That's feedforward: information about what will happen before you act, closing the gulf of execution. Paired with feedback (which confirms what happened), it lets people predict outcomes and avoid errors rather than discovering them. The test is whether someone can tell what a control will do before they touch it.
Feedback comes after an action; feedforward comes before it. Good design uses both: feedforward tells people what a control will do and what's expected (so they can act correctly the first time), and feedback confirms what happened. Clear button labels, hover previews, placeholder examples, "this will delete 3 items" warnings, and showing the result of a setting as you change it are all feedforward. It reduces errors, hesitation and the need to learn by trial - people shouldn't have to click to find out what clicking does. Tell them before, confirm after.
Without feedforward you had to click and hope, then deal with whatever happened. With it, you knew the outcome before committing - so you acted with confidence and avoided the wrong move entirely. That's the value of telling people what a control will do before they use it: feedback fixes mistakes after the fact, but feedforward stops them happening at all.
Feedforward answers the question "what will happen if I do this?" before the action, closing the gulf of execution (Norman's stages of action) at the point where people decide what to do. It works through clear signifiers and labels, hover and focus previews, examples and placeholders, live previews of a change, and explicit consequence warnings ("this will permanently delete…"). It's the counterpart to feedback, which closes the gulf of evaluation afterward.
Good interfaces pair the two: feedforward sets accurate expectations so people act correctly, and feedback confirms the outcome so they know it worked. Relying on feedback alone forces a guess-act-see loop that's slow and error-prone; adding feedforward lets people predict and choose well the first time, which is faster and far less frustrating, especially for consequential or irreversible actions.
Practical feedforward includes descriptive button text (not just "OK"), showing the effect of a toggle or slider live as it moves, previewing what a destructive action will remove, surfacing keyboard shortcuts and tooltips, and disabling-with-explanation rather than failing after submission. The test: can someone tell what a control does, and what's expected of them, before they touch it? If not, you're relying on feedback to clean up avoidable mistakes.