Error messaging patterns are the patterns we use to tell a user that they can’t move forward in their current task because of the state of the system.
The goal of error messaging patterns is not to ensure that we prevent errors, (that’s a different set of patterns) but that when errors occur, the user can recover as quickly as possible to move forward.
TL;DR
Error messages can occur at different levels of the application and in different scenarios:
- Field-level validation and error messaging – This is the lowest level of validation and involves a single field or fieldset.
- Page-level validation and error messaging – This is the next step higher and involves messaging the user about a process-level or form-level issue. Examples include errors that affect multiple fields on a page, errors processing a page, or a page-level error of some other sort.
- Application-level error messaging – This is for notifying the user of an application-sized error. Depending on your environment, you may also have platform-level errors.
- Asynchronous error messaging – in some situations you may want to notify the user that something they’ve been waiting for has finished. For example, if a task has been processing on the server for 10 minutes, you can use these messages to let the user know it finished — or in the case of errors, it didn’t finish.
- HTTP Errors – These errors are the ones that we receive when a server becomes unavailable in a way that the system can’t account for (probably because it isn’t there) .
Each of these scenarios requires a different form of treatment due to the causes and contexts of the errors.
Why this is important
By providing consistent error messaging we:
- Increase the user’s confidence in our applications.
- Increase the user’s confidence in their ability to use our applications.
- Ensure higher efficiency of using the system (because the user isn’t slowed down by poor messaging or confusion).
- Build trust in users that we know what we’re doing and are transparent about it.
Components involved
- Banner
- Toast
- Callout
Use when…
- Error messages are only used for “hard stop” scenarios.
Do not use when…
- The user can proceed but possibly shouldn’t. Use a warning.
- The user can proceed and you have additional information for them. Use an info message.
Additional Resources
A taxonomy for alerts and notifications by Steve Dennis