Error handling is too often an overlooked aspect of UX design. Removing the pain from error experiences is critical because if a user encounters an error, they are probably already frustrated.
Error messages expose the interface. A well-designed interface becomes invisible; the user is not thinking about the interface but about her tasks. So errors are where the interface manifests — where users actively think about the experience. If it’s poor, users will judge the system harshly.
Here, then, is a set of basic guidelines I have developed for those seeking ways to improve their user’s experience of error messages. They are not “best practices”, just a set of general tips cobbled together from various sources, including my own experience. They are mostly aimed at improving form/input errors.
- Avoid the error occurring in the first place
- Show the user the field where the error has occurred
- Use inline validation
- Be polite – don’t blame the user
- Be precise – clearly describe the issue, and how to resolve it
- Reduce the work required to fix the problem
Avoid the error occurring in the first place
Example: in a calendar date-picker, the user should not be able to select a date prior to today.
By making dates prior to today unavailable for selection, a potential error is avoided.
Show the user the field where the error has occurred
After the user clicks the submit button, some pages display error messages in a list near that button, or in a box at the top of the page. The user then has to hunt for the relevant fields. The error message should be near the relevant element.
The examples above are an improvement because the error messages are proximate to the relevant filed.
They also highlight the message text and (in the latter example) the input border, by changing their colour to red.
While the user of red for warnings is a common design pattern, and is usually satisfactory, there is an accessibility caveat. The methods shown above are not sufficient for some colour-blind users, who may not notice when elements turn red.
Do (Accessible Version)
The above examples use a combination of red text with an additional visual indicator (icon / thicker border).
Use inline validation
Error messages that only appear after the user submits the form are particularly annoying, as the user would have been expecting to go to the next page. If there are multiple errors, the form can appear aggressive. There is also a greater risk that the users’ data is wiped with this approach.
Inline validation helps the user to correct the error immediately. It also reduces the wait time before the error appears, and reduces the chance of losing data in the form.
Note: When there are more than a few fields, it is better not to validate blank fields until the user submits the form. Users often don’t fill fields in the order they appear.
Be polite – don’t blame the user
The error message above seems to “scold” the user.
Instead, by immediately pointing out how to fix the error, and by using word “please”, the above message is softer.
Be precise – clearly describe the issue, and how to resolve it
This message is vague.
This message is more precise, and indicates what the problem is so the user can resolve it.
Reduce the work required to fix the problem
In the example above, the username originally entered by the user is now gone.
A better approach is to keep the data the user has entered, so they can see if it looks wrong, and try to fix it.