Today’s error messages are a huge improvement of the error messages of latter years, however they still have a long way to go. I’ve put together the following list of the most common problems with error messages.
Disclaimer: You should always use both server-side and client-side validation. They should complement each other, work well together, and the client-side validation should gracefully degrade. I am very aware of the fact that JavaScript cannot always be relied upon. However, it should be used as the first line of defense with the server-side validation as the last line of defense.
Place error messages close to the field with the error. So many times error messages are placed where it’s most convenient for the programmer to place them. More often than not, it isn’t the best place for the user. The user is forced to find either the error or the field that caused the error and sometimes scroll back and forth if the error is complex.
Clearly label the fields with errors. While this relates to the poor placement problem, it takes it a step further by noting that low contrast on some error messages can make it difficult for the user to understand what went wrong. It’s like telling them they were wrong and then sending them off to find the hidden error message. If they don’t find the error message, they can’t fix the problem. If they can’t fix the problem, they’ll give up. A good example of this is changing the background color of the form field to a bright yellow or something that will differentiate it from the other fields. (Don’t forget color blind users.)
Make sure the error message is easy to read. Error messages can also be too prominent. Since you usually want error messages to be in a bright color that gets the user’s attention, it’s very easy to overdo it so that the message is barely readable. Just make sure that the colors are difficult to look at. (Once again, don’t forget color blind users)
Use detailed explanations. Too many error messages tell you that you’ve made a mistake, but fail miserably at explaining what the mistake was, let alone how to correct it.
Bad Example:
You have entered an invalide phone number.
Good Example:
Please enter a phone number in one of the following formats: (123)456-7890, 123.456.7890, 123-456-7890, 123 456 7890.
Use client-side validation to alert users immediately. Error messages should be presented to the user as soon as possible. If the user has to submit the form before finding a mistake, not only do they have to wait for a trip to the server, but if there is an error and the page included password fields, those passwords will no longer be populated. The user then fixes the error and submits the form, and now they have made another mistake. The password fields are blank, and you have an annoyed user. Similarly, if a user submits a form with multiple errors, the chances of them being overwhelmed and giving up are much higher. I know, I know, not all browsers support JavaScript, and users can turn off JavaScript. You’re 100% correct. That’s why I strongly recommend having both a client-side and server-side validation framework in place.
Use concise summaries. Many error message summaries read like War and Peace. Not only is this overwhelming for the user, but generally summaries are not placed in close enough proximity to the field with the error for the user to fit both on the screen at one time. This forces them to scroll and makes it difficult to correct errors. As long as error messages are placed near the field, it can be helpful for the user to have a basic summary at the top of the form area as a quick summary. It does not, however, need to be as detailed as the error messages that are located adjacent to the fields.
Focus on the first field with an error. After an error has occurred, the focus should be placed in the field that caused the problem. This way the page automatically scrolls to the field with the error and the user is ready to correct it. Of course, if you’re using client-side validation the error should be caught before the user can move on to the next field.
That’s it for some high-level tips. We’ll get into more detail on some of them in future posts.