When users submit content to your site via forms, errors in the data the user has provided is bound to happen from time to time. The goal of this pattern is to improve the user experience by minimizing input errors.
A paradigm suited for determining whether errors happened during form submission is whether the data validates. A common way to tell if data validates is to set up rules for each input field in the form that the entered data must pass to validate. Such validation rules can be:
If the data submitted by the user validates, it is good practice to let the user know that everything went as planned. Even better, redirect the user to a page, where he or she can see the newly submitted content in a context.
However, if the data submitted by the user does not validate, an error message should be presented to the user explaining how to correct the data and request for a re-submit. Such an error message should explain that:
The visual representation of the input feedback should correspond with the message you want to give. If the submission went successfully, consider letting the user know in a green box. If the message is neutral, a color often used is yellow. If something went wrong, red is often used. But beware – red means danger – is the user experiencing a dangerous situation?
As the user fills out a form on a web page, he or she is conducting the process of converting mental data structured in one way to a written form structured in another way. As all humans do not think alike, we are bound to enter the data in different ways as we try to convert our individually structured data to a shared structure defined by the system.
Data entered in web forms is in this way prone to contain errors, which we must be prepared for in our design. The user must be made aware of the fact that the data entered did not match the structure that we designed for. Using visually distinct feedback notices, the user will be made aware of such errors and how to correct them.
It can be argued that you should focus more on preventing errors before the user submits his or her data than on providing a good error message after data has been submitted. Consider constraining input with select boxes.
Consider the language of your error messages, as these may have an emotional impact on your users. What tone of voice is appropriate for your users?
When you are not logged-in to basecamp and try to access a page within your project, you are redirected to a login screen with a positive feedback message telling you to log in first. If you enter a mismatching username
When signing up for a mail at Yahoo, the fields with errors are highlighted and complimenting messages lets you now how to repair the entered data.
Notice the wording of the amazon error messages: a "slight problem" does not mean "danger". Also notice how the problematic field has been highlighted and complimented with a message letting the user know how to repair the problem.
When you have confirmed the validity of your e-mail at digg.com by clicking a link in a received email, a message with positive feedback is shown. Notice how the check mark signals that the task of confirming your email is done and now out of the way.