Effective Error Messages

Unclear and unhelpful error messages tend to mean that errors will recur, or take longer to resolve. The manner in which the user is made aware of how an error occurred, and how it can be corrected, will influence the probability of ultimate success.

State-of-the-art usability engineering should eliminate user errors. But in the real world, those users (the majority) who do not read instructions and prefer to 'figure things out as they go' are inevitably going to come unstuck occasionally. In these situations, interface designers must ensure that the feedback provided is as helpful as possible in setting the user back on the right track.

Unclear and unhelpful error messages tend to mean that errors will recur, or take longer to resolve. The resultant frustration can lead users to mistrust the interface or even abort the task in question. This result can be disastrous, if for example it happens during the course of an online reservation or purchasing process.

The manner in which the user is made aware of how an error occurred, and how it can be corrected, will influence the probability of ultimate success. And there are some basic guidelines that assist developers in this regard. Wherever possible, error messages should meet the following criteria.

Explain the specific problem that has occurred in the clearest language possible. For example, "Invalid entry" should be replaced by "The payment amount entered is too large". Error messages must be understandable without having to read manuals or refer to technical glossaries. In the context of an error message such as "Are you sure you want to delete this cookie!" the user may be left wondering what exactly 'cookie' means.

Error messages often contain system-related information to assist system administrators and expert users. The user should be advised to contact the system administrator in this case. It is advisable to place technical information at the end of error messages. If such information is extensive, it should be accessible through a 'more details' options. This ensures that messages are shorter and hence quicker to read. In this way, innocent users are shielded from technical and specialised information that may only confuse or intimidate.

Error messages should be as constructive and helpful as possible. It can be helpful to offer advice on how to resolve the error at hand. For example, "Enter new value" should be replaced by "Enter number between 10 and 100" - providing the information required to get it right second time around.

Error messages that have the effect of discouraging or embarrassing the user can prove counterproductive. Words such as 'fatal', 'critical', or 'severe' can unduly alarm the user and compound the frustration they feel in having made the mistake. It is important for the user not to perceive the interface as rude or hostile to their input. Unfamiliar and startling sounds or icons accompanying a message can have the same effect. Examples here include "Action Aborted due to file specification error" and "Fatal Application Error". These combinations of alarming vocabulary and opaque meaning illustrate the worst possible type of error message.

'Moving on' from an error message must be as easy and obvious as possible. The interface should allow the user to undo the implied errors and enter new commands without having to begin the entire task over again.