Usability 101: Errors

20 years ago

The usability 101 series continues. Over the past few days, we’ve covered learnability, efficiency, and memorability. Today, we will cover errors, how well the system should prevent them and how it should allow recovery from them.

Things break

You may design the perfect system but eventually, your system will fail. How it does so, however, can make all the difference in the world in terms of usability. As a general rule, users are at their most vulnerable stage when a computer program breaks. It may be because they’ve lost some work or it may be because they don’t like it when computers tell them that what they did did not work. Either way, anyone evaluating software will consider switching application if errors are too common. You may build the best application in the world in terms of future but none of that will matter when your program breaks… unless you can steer the user in the right direction when it comes to responding to errors.

Anatomy of an error message

In order for an error message to be helpful to the user, it needs to include a number of elements:

The message should exist: This may seem like a no-brainer but oftentimes, the main problem with an error is that no error message is attached to it. For example, imagine an email package. For some reason, when trying to send an email, the email package fails. If the user is not notified that this error happened, he or she will assume that every worked great. From the user’s standpoint, no error has happened and he or she will continue using that function. Now ask yourself, is it better for the user to send one email and be notified that there is a problem or is it better for the user to send 20-30 emails before learning that people on the other end did not receive anything? The answer should be fairly obvious. Notify the user when the error happens, every time it happens. The error may be due to a flaw in the software or a flaw in the way the user is using the software but if the user doesn’t know, he or she will assume that the problem is with the software.
The message should be understandable: Often, error messages provide absolutely no information to the user. A message that says “Error 12312 Bad Syntax” provides absolutely no information to the user. As a result, you should think of what a normal person (read: someone who does not program) needs to understand what the error was. Sometimes, something as simple as a plain explanation goes a long way in helping the user feel better. An example of a good error message could be, for example “Sorry, your file was not saved because the hard drive is full.”
The message should be precise: A message that just says “Syntax Error” is not really doing its job properly. The reason is that this kind of error could be coming a number of times from a number of places. This is not helpful to the user (as the user is not aware of what the problem is) and is not helpful to the programmer (as the programmer will not be able to know what happened when the user says that he or she got this error). A precise error message makes everyone’s life much easier as it gives a clear set of information related to the particular error to both the user and (when the user speaks to a programmer) to the person in charge of fixing the problem. If your messages are clear, your product will be easier to fix.
The message should be correct: When errors messages are inputted at the last minute, there is often a tendency to shove any error message anywhere. As a result, an error message could be popping up that has nothing to do with the error at hand. Check your error messages carefully to ensure that they are indeed providing information about the right type of error.
The message should be consistent: Oftentimes, people get carried away with error message writing. However, you should consider setting up a standard way of presenting your error message. Generally, an error message pops up in a separate box (in a GUI interface) to increase a user’s attention to it. In a non graphical user interface, it would probably appear in the same screen. If you are switching back and forth between the two mode, choose one way to present your error messages. Once you’ve done so, figure out the format of your error message. For example, an error message could be including the following elements:
- A message or icon specifying that this is an error (eg. “Error:”)
- A clear description of what the error is
- A line break
- A short explanation as to what the user can do to fix this
- A line break
- An OK button to allow the user to close the box
An error message should be helpful: We are talking about usability here. So let’s not forget that this error message should be usable. One way to make it so, for example, is to provide a short description as to how the user can fix the error. Another way is to give the user a button to notify the programmer of the error (this would, hopefully, send more information to the programmer so he or she can fix the error in a subsequent release of the application)

A note on presentation

As I pointed out earlier, error messages generally do not make a user feel good. Because of that, there are certain things that you should consider in the presentation of your error message.

Color: One would think that an error message should be printed in red to call attention to itself. To use color solely as the way to present an error message is generally a bad idea. The reason: there are people out there who are color blind. Presenting the message in a particular color will not make an iota of difference to them.
Language: If your application is used by people in different countries (and if you’re an open source developer, you are probably hoping it will be), consider the fact that error messages will have to be translated. Yes, it’s a pain but oftentimes, it is something that is overlooked and causes much annoyance on the part of the user
Error message on Macintosh computers used to show a bomb

Icons: Be careful of what icons you use to present your error messages (if you plan to use icons). A good example of this was the small bomb on the original mac computers. When an Apple Mac crashed, it would show an icon presenting a little bomb. Users in many country were terrified by this icon and would not touch the computer, for fear that it would explode. This is a true story, which should highlight how careful you should be when considering icons related to errors.