Usability 101: Errors

The usabil­ity 101 series con­tin­ues. Over the past few days, we’ve cov­ered learn­abil­ity, effi­ciency, and mem­o­ra­bil­ity. Today, we will cover errors, how well the sys­tem should pre­vent them and how it should allow recov­ery from them.

Things break

You may design the per­fect sys­tem but even­tu­ally, your sys­tem will fail. How it does so, how­ever, can make all the dif­fer­ence in the world in terms of usabil­ity. As a gen­eral rule, users are at their most vul­ner­a­ble stage when a com­puter pro­gram breaks. It may be because they’ve lost some work or it may be because they don’t like it when com­put­ers tell them that what they did did not work. Either way, any­one eval­u­at­ing soft­ware will con­sider switch­ing appli­ca­tion if errors are too com­mon. You may build the best appli­ca­tion in the world in terms of future but none of that will mat­ter when your pro­gram breaks… unless you can steer the user in the right direction.

Anatomy of an error message

In order for an error mes­sage to be help­ful to the user, it needs to include a num­ber of elements:

• The mes­sage should exist: This may seem like a no-brainer but often­times, the main prob­lem with an error is that no error mes­sage is attached to it. For exam­ple, imag­ine an email pack­age. For some rea­son, when try­ing to send an email, the email pack­age fails. If the user is not noti­fied that this error hap­pened, he or she will assume that every worked great. From the user’s stand­point, no error has hap­pened and he or she will con­tinue using that func­tion. Now ask your­self, is it bet­ter for the user to send one email and be noti­fied that there is a prob­lem or is it bet­ter for the user to send 20–30 emails before learn­ing that peo­ple on the other end did not receive any­thing? The answer should be fairly obvi­ous. Notify the user when the error hap­pens, every time it hap­pens. The error may be due to a flaw in the soft­ware or a flaw in the way the user is using the soft­ware but if the user doesn’t know, he or she will assume that the prob­lem is with the software.
• The mes­sage should be under­stand­able: Often, error mes­sages pro­vide absolutely no infor­ma­tion to the user. A mes­sage that says “Error 12312 Bad Syn­tax” pro­vides absolutely no infor­ma­tion to the user. As a result, you should think of what a nor­mal per­son (read: some­one who does not pro­gram) needs to under­stand what the error was. Some­times, some­thing as sim­ple as a plain expla­na­tion goes a long way in help­ing the user feel bet­ter. An exam­ple of a good error mes­sage could be, for exam­ple “Sorry, your file was not saved because the hard drive is full.”
• The mes­sage should be pre­cise: A mes­sage that just says “Syn­tax Error” is not really doing its job prop­erly. The rea­son is that this kind of error could be com­ing a num­ber of times from a num­ber of places. This is not help­ful to the user (as the user is not aware of what the prob­lem is) and is not help­ful to the pro­gram­mer (as the pro­gram­mer will not be able to know what hap­pened when the user says that he or she got this error). A pre­cise error mes­sage makes everyone’s life much eas­ier as it gives a clear set of infor­ma­tion related to the par­tic­u­lar error to both the user and (when the user speaks to a pro­gram­mer) to the per­son in charge of fix­ing the prob­lem. If your error mes­sages are clear, your prod­uct will be eas­ier to fix.
• The mes­sage should be cor­rect: When error mes­sages are inputted at the last minute, there is often a ten­dency to shove any error mes­sage any­where. As a result, an error mes­sage could be pop­ping up that has noth­ing to do with the error at hand. Check your error mes­sages care­fully to ensure that they are indeed pro­vid­ing infor­ma­tion about the right type of error.
• The mes­sage should be con­sis­tent: Often­times, peo­ple get car­ried away with error mes­sage writ­ing. How­ever, you should con­sider set­ting up a stan­dard way of pre­sent­ing your error mes­sage. Gen­er­ally, an error mes­sage pops up in a sep­a­rate box (in a GUI inter­face) to increase a user’s atten­tion to it. In a non graph­i­cal user inter­face, it would prob­a­bly appear in the same screen. If you are switch­ing back and forth between the two mode, choose one way to present your error mes­sages. Once you’ve done so, fig­ure out the for­mat of your error mes­sage. For exam­ple, an error mes­sage could be includ­ing the fol­low­ing elements:
  • A mes­sage or icon spec­i­fy­ing that this is an error (eg. “Error:”)
  • A clear descrip­tion of what the error is
  • A line break
  • A short expla­na­tion as to what the user can do to fix this
  • A line break
  • An OK but­ton to allow the user to close the box
• An error mes­sage should be help­ful: We are talk­ing about usabil­ity here. So let’s not for­get that this error mes­sage should be usable. One way to make it so, for exam­ple, is to pro­vide a short descrip­tion as to how the user can fix the error. Another way is to give the user a but­ton to notify the pro­gram­mer of the error (this would, hope­fully, send more infor­ma­tion to the pro­gram­mer so he or she can fix the error in a sub­se­quent release of the application)

A note on presentation

As I pointed out ear­lier, error mes­sages gen­er­ally do not make a user feel good. Because of that, there are cer­tain things that you should con­sider in the pre­sen­ta­tion of your error message.

• Color: One would think that an error mes­sage should be printed in red to call atten­tion to itself. To use color solely as the way to present an error mes­sage is gen­er­ally a bad idea. The rea­son: there are peo­ple out there who are color blind. Pre­sent­ing the mes­sage in a par­tic­u­lar color will not make an iota of dif­fer­ence to them.
• Lan­guage: If your appli­ca­tion is used by peo­ple in dif­fer­ent coun­tries (and if you’re an open source devel­oper, you are prob­a­bly hop­ing it will be), con­sider the fact that error mes­sages will have to be trans­lated. Yes, it’s a pain but often­times, it is some­thing that is over­looked and causes much annoy­ance on the part of the user
• Icons: Be care­ful of what icons you use to present your error mes­sages (if you plan to use icons). A good exam­ple of this was the small bomb on the orig­i­nal mac com­put­ers. When an Apple Mac crashed, it would show an icon pre­sent­ing a lit­tle bomb: Users in many coun­try were ter­ri­fied by this icon and would not touch the com­puter, for fear that it would explode. This is a true story, which should high­light how care­ful you should be when con­sid­er­ing icons.

So remem­ber that errors will hap­pen but that what will make all the dif­fer­ence in the world is if they are han­dled properly.