4 rules for displaying error messages from a user experience perspective
1st July 2010
By Tasin Reza, filed under Usability.
Comments 18
4 rules for displaying error messages from a user experience perspective
Outline
In order to display error messages on forms, you need to consider the following four basic rules:
- The error message needs to be short and meaningful
- The placement of the message needs to be associated with the field
- The message style needs to be separated from the style of the field labels and instructions
- The style of the error field needs to be different than the normal field
By combining these four rules, it is possible to provide the necessary information to users where they have made mistakes on filling in forms and how to rectify them quickly and easily. This will encourage and help users to continue with their journey on the site; reduce basket abandonment; increase site registrations; increase enquiries about an application form and so forth.
Introduction
A typical interaction with many websites is filling in forms. For example, if you are buying something online, you have to give your card details, delivery address and other personal information. By clever placement of labels, instructions to fill in a field and additional design elements can make a form less daunting and may result in fewer mistakes made (Jarrett, C. and Gaffney, G., 2008).
However, I have seen that users make the same mistakes on forms again and again as these websites show error messages which are either not very clear to the user or because of their placement; users are unclear what messages relate to. This article focuses on how to provide error messages on forms from a user experience perspective.
The message
The error message needs to be clear, precise, short and punchy. Users should be able to immediately understand what ‘mistakes they have made’ and how to recover the error. This is fundamental and will have a huge impact if users can’t immediately understand what mistake they have made.
One example of an unclear error message is on the Hotmail registration page where it asks for user’s ‘Birth year’. I remember using only two digits to represent a year before the year 2000. Well, the form does not give any instruction on that; even the error message does not give a clear idea of what was wrong with entering two digits for my birth year.
Figure 1: Hotmail registration page- error message not providing how to put the birth year (e.g. ‘yyyy’)
I know I was born in ’81 and I can verify it with my birth certificate. The error message should mention the format of the birth year that the user needs to follow, for example “Please enter birth year in 4 digits (e.g. 1973)” as shown in the following figure.
Figure 2: Improved error message to make it clear to people what mistake they have made
The placement
Not only does the message need to be short and concise, but it also needs to be well placed to associate it with the field. This poses the question of where is it best to place an error message- above, after, left or right of the field?
This depends on the type of the error message. If it is a ‘missing required field’ error, you can either place it on top, to the right or to the bottom of the field.
Figure 3: Showing example of ‘missing required field’ error messages at the bottom of the associated fields (from eBay)
Figure 4: Showing example of ‘missing required field’ error messages above the labels
The association between the field and the error message needs to be visually clear. Although this might not be a large usability issue for smaller forms like Figure 5 (Google login form), for a long form, this might significantly confuse and lead to repeated mistakes (as shown in Figure 6).
Figure 5 : Google login error message
Figure 6 : Error messages displayed the same way as Google login for a long form which might confuse users
For an ‘instructional’ error message, it is particularly important to consider careful placement as we need users to read the instruction and follow it to fill in the field.
Previous research on label placement by Matteo Penzo and further investigation by Caroline Jarrett revealed that instructions for filling in forms work best when placed above the field. Therefore, if it is necessary for the user to read an instruction to fill in the field, it is best to also provide the error message at the top of the field. For example, the Linkedin registration form provides both types of error message (‘missing required field’ and ‘instructional’ error messages) at the top of the field and just beside the labels. By doing this, when a user is completing the form, they would read the label, then look at the error they have made (and how to rectify it) and then re-enter their answer in the field after the error message.
Figure 7: Error messages displayed matching user reading pattern
So, what about long forms? We have seen from our previous experience that if a user makes a mistake filling out a long form, and the field in error is below the fold, they get confused trying to understand what happened.
Figure 8: Example of a long form (from The Common Application)
To prevent this, it is necessary to list the errors at the top of the page as well as showing the error messages associated with the fields. This will give a clear indication to users about where they have made mistakes.
However, it is necessary to make sure that these error messages don’t overwhelm the users as in the example shown in Figure 9.
Figure 9 : Error messages shown at the top and with the associated fields (Sainsbury’s register page)
The message style
Users must be able to distinguish between form labels, instructions and error messages. Using different font size and colour will provide visual cues to users about why the form could not be submitted and what mistakes they made.
The field style
In addition to the message style, the style of the error fields needs to be distinguishable from the normal input field. This usually helps in a long form where the user made only one or two mistakes. They can then easily spot where they have made mistakes and rectify them.
Figure 10: WordPress registration form giving a different border style on the error field
Example of using the 4 point rules for displaying error messages
In a usability testing session of an e-commerce website, one tester was trying to purchase a product. This particular website requires all users to be registered before the purchase process begins. During the registration process, the user filled out the form with her name, a username and a password and submitted it. The same form was then displayed with an error message (Figure 11): “Please type a new user name with a mixture of alphanumeric characters ranging from 6-14 characters. This has to be unique for all of our customers.”. Additionally, the password field where she had entered her desired password became empty.
Figure 11 : Error message display after submitting a registration form
The tester thought that she had made a mistake with the password. So she entered a new password with numbers, characters and capital letters, re-entered it, and submitted the form. The same thing came up again. She was certain that the password she had given had a mixture of characters and numbers with capital letters, so why wasn’t it working? Frustrated with the system, she re-read the message slowly and finally understood where she was making the mistake; it was the ‘user name’ she needed to worry about and not the password. So she entered a different user name with all the necessary characters and submitted the form. This time the form said that the password field was empty…
Although this happened in lab conditions, I am not sure how desirable the product has to be to persevere with this registration process to buy it. Her response was to gve up and try to find the same product on another website.
Now, what went wrong?
First of all, the form was poorly designed without any instructions up-front about the user name. But that’s a whole other topic of designing effective forms and where to put instructions (about which Caroline Jarrett and Luke Wroblewski have written some great articles and books).
Secondly, the way of describing the error was poor. Let’s put it into perspective- someone is trying to buy something from you, they don’t have the whole day to read a big explanation of “Why they are wrong!”.
Thirdly, the position of the error message made it unclear to the user which field it was related to.
And finally, there was no visual cue for which field the user had to modify to rectify ‘their’ error. This made the user change her password rather than changing the username resulting in the same error message coming up repeatedly on the form.
Using the basic 4 point rules of displaying error messages
If we adopt these rules for the example shown above, we can come up with multiple solutions.
Displaying error messages on the forms with labels placed on the left:
For example, if we want to fix the error message which said “Please type a new user name with a mixture of alphanumeric characters ranging from 6-14 characters. This has to be unique for all of our customers.”, it might become something like “User name must be 6-14 characters long and must contain at least 1 number and 1 character.”.
Using placement and styling rules, we can provide the following example:
Figure 12: Example of using the 4 point rules of displaying error message
Displaying error messages following a user’s reading pattern:
If the labels are provided above the fields, following example shows how you can provide the error messages and match a user’s reading pattern:
Figure 13: Example of using the 4 point rules of displaying error messages on a form
Conclusion
Ever changing web technologies and evolving user behaviour towards the web makes it difficult to standardise web experience. However, we can attempt to make things better by providing a good user experience from what we have learnt. At Nomensa, we conduct experiments to identify best practice and solutions. We witness people struggling to fill out different types of forms on a daily basis. By using the combination of the four rules to display error messages and our own methods of multi-variant testing to display error messages, we can help people achieve their goals as smoothly and as quickly as possible.
Displaying form error messages might be a small part of a large website, but it can have a significant impact on people, especially if they cannot understand the mistakes they have made. This would ultimately cause them to leave the site. By combining these four rules to display error messages, you can tell people very politely what mistakes they have made and help them to easily recover and complete their journey.
References
- Jarrett, C. and Gaffney, G., Forms that work, Designing web forms for Usability, 2008.
- Penzo, M., Label Placement in Forms, Published in UX Matters, July 2006.
- Wroblewski, L., Web Application Form Design, January 2005.
About the author
Tasin (AKA Tas) was cursed by the humanisation of the e-world years ago… and now he complains about everything that is unusable by humanoid.
A well written and interesting post!
Yes, excellent post with great screenshots to illustrate your points. Thank you very much for this – it will be a handy reference for future discussions on usability.
so what about this hard-to-read-font u are using in this website?????
Thanks for your comments. We apologize, we were experiencing a publishing error. We completely agree that the uppercase on the site is not very readable. We have now fixed this. We hope you enjoy the article and keep your comments coming!
For long forms with several error messages that need to be displayed (such as figure 9), I’d think a simpler way to do this would be a note in red at the top saying “Several required fields were not completed as they should. The fields are highlighted below.” I’d then paint the areas around the fields with errors in a pale red. This would be much less intimidating to users – or would to me, anyway.
Also it’s good to tell users things like “you made a mistake,” “your entry is incorrect,” “you have not filled out the form correctly” etc.
People LOVE that. mmmmm
/kidding
As a developer it’s always nice to see helpful instructions on where to put error messages. My only word of caution after you have found out where to put them and how to format them is what to put in it. If you are simply filling out a form there isn’t much to worry about but if you are signing in then that’s where it is easy to give away too much information such as “wrong password”…bad idea. From a security standpoint you don’t want to give out too much information unless you are just doing data validation.
Great job Tasin. Its a common thing that we all often overlook.
Well written and illustrated blogpost.
Food for thought!
This is a good article with good examples.
I didn’t find example 12 or 13 very interesting. This is not UX. It is force fitting user behavior to fit the programmer’s mental model of the problem.
This is how you “fix” the problem ten days before launch.
One UX solution is allow four character (or three or one) user names, without unnecessary constraints. Unnecessary is an important word.
Should security be an issue, EXPLAIN WHY within the error message. There is nothing so frustrating as to have a computer slam back an error with no context, and that’s just what you do with these rather poor examples.
A number of sites explain the Seurity Strength of, say, a password. Which is much better for the User Experience.
Sad to say, this seems like it was written by a programmer to explain why they did something and why the user should simply shut up and take it.
Reasonable tips, and here is another one.
1. When switching to an error screen for a form, DO NOT clear any fields. And certainly do not clear ALL fields.
It seems about half of sites will trash my carefully entered detailed information when there is an error.
And one more that is related to that one:
2. Handle cases where the user uses the Back and Forward button in the browser without losing user data.
To bad you didn’t apply these rules to your form.
If users are entering years as 2 digits and having problems, the root cause is that the application doesn’t accept (possibly with a warning) 2 digit years; it isn’t just that the error message explaining what happened is insufficiently clear about the application’s demands of the user.
Great article to start a discussion. It spawned a lengthy tirade I imposed upon my developers about good UI design since I found non of these examples “good”, even the ‘fixes’. The reason is that while I understand the article is about presentation of errors, the examples perpetuate a more serious underlying part of errors: avoidance. i.e. You don’t WANT the user to see an error message if it can be avoided with a little forethought.
What’s wrong with each figure:
Figures 1/2. While the error message may be bad, the label SHOULD have been “Birth year (e.g. 1974)” in the first place and chances are the user will never see the error. Secondly, there’s some algorithms that prevent this stemming from Y2K: 1) most software is fine inferring 1900s for years < current. 2) after the user tabs off the year add a 19 to the beginning and allow the user to correct it if it's wrong.
Figure 3. The UI is polluted with all these annoying "Please enter your “. This isn’t needed. There’s already an ‘*’ that indicates a required field. A simple error message at the top saying “You are missing the indicated required fields” with the red arrow icons in front of the fields that are missing is MUCH more aesthetic than sprinkling red text all over the UI. Use red text sparingly for when it’s needed, e.g. “Core meltdown”, or you are simply conditioning your users to ignore red text.
Figure 4. Again, a little label of “Windows live ID: (examples@hotmail.com)” will prevent the user from simply entering a username. If you require a email address, bloody well state it up front to prevent the user from entering the wrong thing. And two error messages is really unreasonable for a login. A simple “login failed, if you have forgotten your username or password click here” will suffice.
Figure 5. *sigh*. users. This one is the best of the examples simply because it’s so simple; the user neglected to enter the most important of the TWO pieces of login information. *sigh*. This means either it’s a mistype or the user is not familiar with logins. However note that you can either type “user@gmail.com” or “user” in the username and it takes either one. Points to google for forethought.
Figure 6. Again, enough with all the red text. Add an “*”, throw up an icon in front of each textfield, and have a single error at the top “missing required information”.
Figure 7. Completely agree with predicting the reading flow of controls, but again with all the red text.
Figure 8. Your next article should be about layout. Web designers beware, if you *insist* on making the web form look like the paper form prepare yourself for the user missing fields here and there. So the “NOTE”s should not be in red because you’re going to need to save the red text for all the missed fields.
Figure 9. C’mon, there’s more red text than black text, even without the header. This will panic the user if they see all that red. And isn’t “Please let us know if you would like us to contact you or not by selecting one of the options below” just a little too wordy? The text is superfluous to the black text immediately above it. All it needs to indicate is there’s an error and let the user fix it or research more by saying “You must choose from one of the following options” and they can read about the options on their own.
Figure 10. This is actually a nice login. The best part is it explicitly states 4 chars and the security validation pattern. Although the error says nothing of what went wrong (I’m assuming this is meant solely as an example of how to highlight error fields?)
Figure 11. Firstly, just like Figure 10, if the username must conform to some security pattern, state the pattern BEFORE the user selects a username. With the stated validation pattern it almost guarantee the user will reach an error state. Secondly, what is the purpose of “This has to be unique for all of our customers”? How does the user know if it’s unique. Why does the user care? There’s nothing the user can do about uniqueness unless there’s a list of all the current users. So don’t mention it in the error message unless the username already exists, then explicitly state “username already exists, if you forgot your password…yadda yadda yadda”
Figure 12, 13 See Figure 11.
Again, I know these examples are for illustrative purposes of error presentation, but most of the illustrations are just plain bad UI design. Remember, the most important things about errors is how to prevent your users from ever seeing them.
my $0.02
If your form is asking for my birth year, any two digit number greater than “this year minus five” must be in the previous century, if we assume that a user must be at least five years old to use a computer, read the text, and enter his birth year in the appropriate text field. The odds of anyone over 100 years old using our web site is miniscule, but I think they will enter a four-digit year.
This goes along with web sites that force me to enter credit card numbers, phone numbers and other information according to THEIR formatting rules. How about asking the user to enter their phone number ( “format is any way you like, we’ll ignore anything other than numbers” )?
Thanks to u for such a wonderful post , these may appear silly for some but they do really matter
Thank you all for your comments, ideas and additional tips.
@Bill: Nice catch. We were talking about the error messages on our blog posts. This is the WordPress default form error message and we are trying to change this to follow the rules.
@Douglas McClean: May be you are right- it might be the technical limitations. But all the users need to know is what went wrong and how to rectify it (the first rule).
@Design Crux: Thanks for your comment. Regarding figure 12 and 13, this was just to provide an example based on our experience of working with a client where the original error message is provided in figure 11 (which you might not have noticed).
Just to confirm, this was to show what could be done in a ‘particular situation’ using the 4 rules to display error messages in a meaningful way. I could have talked about the technical specification (which users don’t care about) to tell the user why 4 characters (or 3 or 1) but in this case, it was not necessary.
Another thing I mentioned in this article, this was about how to display error messages so that users can easily understand what mistakes they have made and rectify them quickly, rather than how the form should be designed or background functionality should work.
I hope this clears any confusion you might have regarding this article.
@UI Stalin: Thank you for taking time to reply with each and every figures/examples shown in this article! As you said that this article is about displaying error messages on forms, you are spot on!
As I mentioned in the introduction, that you can avoid errors made by users in most cases by clever replacements of labels and instructions to fill up a form, but what happens if a user still makes a mistake?
Most examples shown here provide instructions or use ‘*’ to show which ones are required and I just wanted to show what happens if still users ignore these, how these forms are showing error messages.
Finally, I completely agree with you that “the most important things about errors is how to prevent your users from ever seeing them” on which C. Jarrett, M. Penzo and L. Wrobleski wrote some great books, research papers and articles as I mentioned in the introduction. But this was about displaying error messages.