Feedback and Feedforward: The Interface That Responds and Anticipates
Feedback confirms what happened after an action; feedforward anticipates what will happen before it. What NN/g says about system status and response times.
What is feedback, and why does it matter?
NN/g includes visibility of system status among its usability heuristics: the system should keep users informed about what is going on, through appropriate feedback within reasonable time (NN/g: Visibility of System Status). Its examples include a button that changes color and shows a checkmark after a selection, and a progress indicator when a process takes a little longer.
NN/g also notes that these heuristics are broad rules of thumb rather than specific guidelines, and that feedback should reach the person as quickly as possible, ideally immediately (NN/g: Ten Usability Heuristics). A form that says nothing after you submit it forces the person to wonder whether the click worked. That doubt produces repeated clicks, and repeated clicks produce duplicates.
What is feedforward?
Feedforward is information that appears before the person acts and tells them what will happen. Examples: a button label that reads “Delete forever” instead of “Delete,” a preview of how a theme change will look, or a notice that an action cannot be undone.
The term comes from the interaction design literature, not from the NN/g heuristics. Vermeulen, Luyten, van den Hoven, and Coninx (CHI 2013) present it as a way to cross Norman’s gulf of execution, the distance between what a person wants to do and the actions the system allows. Feedback, by contrast, helps evaluate what already happened. Use it as a practical design principle: before acting, the person should be able to tell what will happen.
How do you apply both?
Think of the flow in three moments: before the action, during the wait, and after the result.
- Before (feedforward): the label states the outcome, the icon matches the action, and irreversible risks are flagged.
- During (feedback): the button changes state, a loading indicator appears, or the system shows that it is still working.
- After (feedback): a confirmation, a success message, or a clear error that says what to do next.
For waiting times, NN/g describes three well-known limits. At 0.1 seconds the response feels instant and needs no feedback beyond the result. Around one second, the flow of thought stays uninterrupted, but it helps to show that the computer is working, for example with a cursor change. Beyond ten seconds, attention drifts, and a percent-done indicator and the option to interrupt are needed (NN/g: Response Times: The 3 Important Limits). For the discussion of the 400 ms threshold, see the Doherty threshold.
When should you NOT add more feedback?
- When the response is already instant. A confirmation animation for an action that takes 50 milliseconds adds noise.
- When feedback repeats on every screen. If everything confirms everything, people stop reading it.
- When a progress indicator does not reflect real progress. A bar that fills by itself misleads, and people stop trusting it.
Illustrative example
Illustrative example: a bank transfer app has a “Send” button that, when tapped, changes nothing for two seconds. People tap it again and, in some cases, duplicate the transfer. The team makes two changes. Before sending, the summary reads “$500 will be sent to Ana López today” (feedforward). When the person sends, the button changes to “Processing…” the instant it is tapped and becomes disabled (feedback). When it finishes, “Transfer sent” appears with the reference number. Duplicates fall to zero, even though the server time did not change.
If the waiting moment ends in an error, how you communicate it matters as much as the feedback: review prevention and recovery from errors and the text of error messages. And to decide between a skeleton screen and an optimistic version, read skeleton vs. optimistic UI.
How do you know it works?
A simple test: ask someone to complete the main action without giving them instructions, and watch the moment they hesitate. That pause usually marks the point where feedback or feedforward is missing. If the person asks out loud “did it send?” or taps twice, you have identified the problem. Also note what they say: if they answer “I think so,” the interface did not give enough confirmation.
Common mistakes
- Leaving the person with no response after a click.
- Showing a spinner that never ends when the wait has already passed several seconds.
- Using visual feedback as the only channel, with no text for people who do not see the change.
- Using generic labels such as “OK” on irreversible actions.
- Showing a progress bar that does not match real progress.
- Confirming every minor action with a message, so the important ones go unnoticed.
What you can do tomorrow
- Walk through your main flow and note every action that has no visible response within one second.
- Review the labels on irreversible actions and ask whether they say exactly what will happen.
- Pick one wait longer than ten seconds in your product and decide whether it needs a percentage, a cancel option, or both.