Feedback Messaging
One of the most important things that an application does is provide feedback to the users. Feedback as an interaction category can involve a number of different components – and can use different components at the same time.
TL;DR
Feedback breaks down into multiple categories including:
- Error Messages
- Warnings
- Success
- Information (info)
Feedback can be given:
- Synchronously, as if it’s part of the flow
- Asynchronously (from the user’s standpoint) a minute or longer after the initial interaction
The component(s) used to provide feedback depend on the type of feedback being given and whether it’s synchronous or asynchronous communication.
Whenever possible, make feedback short, to the point, and effective.
Not all situations (especially success) require feedback.
Pattern description
This is a parent page for multiple other patterns.
What all feedback patterns have in common
- They all treat the user like an adult, while acknowledging that the user may not be an expert either in the field or in the application being used.
- The feedback itself is succinct, and additional explanation is provided elsewhere when necessary.
- Whenever possible, a call to action is provided.
Why this is important
By providing consistent feedback patterns, we:
- Increase the learnability of our systems
- Lower the cognitive load of the systems
- Ensure higher recognition of error states
- Build trust in users that we will consistently and effectively communicate with them
Use when…
The system needs to communicate to the user. These situations include:
Errors occur
Errors are “hard stop” scenarios. The user has a task, and that task cannot be completed in the current state. This could be because a form is filled out incorrectly, the user has made a choice that isn’t consistent with the system state, or the system itself is experiencing an issue.
The system needs to warn the user of consequences
Sometimes the user makes a choice that could lead them down a path they don’t actually want to be on. (We’ve all had those days where we don’t read the dialog before we click the OK button.) It’s our responsibility to ensure that they’re aware of the impacts of their choices especially when data will be destroyed, a setting will be changed that can’t be changed back, or the most obvious choice may be wrong for them.
The most frequently-coded subcategory of warnings is “cancel warnings” where a user enters a form, starts to provide data, then attempts to leave either via the cancel button or through the global navigation on the page. When these occur we confirm that the user knows they’re going to lose the changes they made, in case they didn’t actually mean to leave.
Something processed successfully
See “Do not use when” for specific caveats around this messaging category.
If the user has done something complex, they may need to be notified when the process is done. This is especially true of long serial processes.
If the user has done something, but the action won’t process in the system immediately, they may need to be notified when the process is done. This is especially true of anything that processes overnight, or in a large batch that takes more than 30 seconds to complete.
Additional information (info messages)
Sometimes we want to inform a user on the state of the system but they’re not required to take action. Sometimes we want to provide them information about an action they can take, but because the action has no negative consequences, a warning or error is inappropriate. Examples may include:
- We logged you out.
- The data on this page is impacted on the data on this other page, and you can access the other page over here.
- You can add [thing] to this [process] for [better result].
Do not use when…
- Do not use the wrong category of feedback message. This happens most often when we code something as an error when it’s really a warning (and vice versa).
- Do not overwhelm the user with feedback. “Instructional content” and “Feedback” are two different categories of content.
- Just because you wrote it on the page doesn’t make it an info message.
- If a form posted correctly and the next screen the user sees shows them the result, they don’t need to be told that it was successful.
- Do not write messages that leave the user feeling uninformed or unsupported. Especially for errors and warnings, you must provide the user with some idea of what they’re supposed to do about the situation.
Examples and counter-examples
See: