Error messages are a necessary part of every form
On electronic forms, error messages indicate when input is missing or invalid.
Even if your form has been carefully designed with great user experience in mind, you’ll still need error messages as form-fillers are…well…only human. We all make typographical mistakes, accidentally miss fields and make our own, sometimes unusual, interpretation of questions and field labels.
Principles of good error message design
There are plenty of solid articles on the web that enumerate the principles behind well-designed error messages, from Jakob Nielsen’s advice in 2001 to the relevant section of the current Windows User Experience Interaction Guidelines. A recent article that is a favourite of ours is “Communicating errors” by UserFocus in the UK.
All of these guidelines boil down to one small and straightforward set of principles that apply to each error:
- tell the form-filler that an error has occured;
- be clear about exactly what and where that error is; and
- provide the form-filler with the information and tools they need to be able to correct the error, or otherwise get out of the situation.
Underlying these principles is a more general one about forms: be respectful of the user. A form is a conversation between two parties and like the equivalent in real life, being rude doesn’t help anyone. This is especially the case when you consider that error messages are delivered at precisely the point where the user has encountered a barrier to task completion.
The missing example: error messaging done well
The numerous guidelines and articles available on the web are supplemented by design patterns on sites like Welie.com (called “Input Error Message”) and UI-patterns.com (called “Input Feedback”). And while all of the aforementioned resources include examples of poor error messages, you can always get more from a showcase like the one on Elements of Design or the plethora on Flickr (a favourite is “Interface Insults”).
So with all this information, why are we writing yet another article on error messages? Because we think there’s just one little thing missing from this resource pool: a clearly illustrated example of error messaging done well.
Below you’ll find a screenshot from an online car insurance quote interface. We think this illustrates the key characteristics of well-designed error messaging. Note that so you can see them better, you’ll find the relevant parts of the screen shown also in Figures 2-4. You can also click on any image to see a bigger version of it.
Figure 1: Screenshot of a web-based car insurance quoting form.
The key features of this example are as follows:
- Errors are summarised at the top of the page (this is the part of the screenshot referenced with the number 1). In this particular case, the errors are split into two groups: questions without any answer; and questions for which the answer is invalid.
- Within each of these sub-groups, the order in which errors are presented is the same as the order those errors occur in the form.
- Each error is highlighted in the place where it actually occurs on the form itself (an example of which you can see at the numbers 2 and 3).
- Both colour and icons are used to visually highlight the errors, with consistent styling applied throughout. Using both colour and icons means the error styling is accessible to those with colour-deficient vision.
- We chose to use red as our colour as it seems to be becoming a de facto cue for errors around the internet (for Western websites at least – we know red may not be so suitable for other cultures).
- We use an exclamation mark (“!”) as our icon because it has a history of being used on hazard and warning signs etc, which try to attract the eye to something that needs immediate attention.
- Each error in the summary is an anchor link to the error itself lower down in the form, making it easier for the user to quickly locate and fix problems.
- When the error is described it’s clear whether the problem is one of omission or validity. Omission is when there is no answer but there needs to be. Validity means the answer given is not acceptable (e.g. outside allowable ranges).
- The language is non-technical, non-accusatory and focuses more on what needs to be done to ‘get across the finish line’, as it were, than what has already gone wrong.
Figure 2: Close-up of the error summary. Notice how errors are presented one per bullet, with the bullets divided into two groups according to whether the answer is missing or invalid. This is a nicely-scalable solution, in that it copes with any number of errors of either type.
Figure 3: Close-up of the first error (invalid date).
Figure 4: Close-up of the second error (missing data).
Now, we’re not suggesting that the specific implementation shown here is the only way that error messages can be designed well. Rather, we wanted to show just one example of how the relevant principles can be put into practice. That way, we hope we are providing you with a guide for checking your own designs.
Indeed one potential refinement to this approach would be to include an error message like “Please provide an answer for this question” underneath questions that have not been answered but must be. Testing would show whether simply highlighting the question is enough or whether an explicit instruction is needed.
What about inline validation?
Obviously the solution presented here refers to the results of server-side validation. A different design approach is needed if you’re validation errors “inline” (i.e. as the form-filler moves from one field to the next). On all but the smallest and simplest of web forms, however, there will be a need for some server-side validation.
Over to you
Do you have examples of well-designed error messages that you’d like to share? Let us know in the comments.
We’d also love to hear suggestions of modifications to this design that you feel would improve the communication of errors.