Users are human; it seems like a moot point to bring up but it is important to remember. Why? Because humans screw up. Humans make errors, and as we’ve discussed no technology can be made error-proof. Not only that, making you technology error-proof shouldn’t be the goal…it will only send you down the rabbit hole. So how can we deal with errors keeping in mind the usability of the system?
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
– Dr. Jakob Nielsen, 10 Heuristics for User Interface Design
When a user encounters an error in a platform or webpage, either from their own use or from a genuine bug in the system, it is stressful for them. This is especially true if they are using the platform or technology for their job. How much of their work did they lose? Do they have to start over? Can I fix the error where I am or is it somewhere three screens ago? Now is the time to indicate where the problem lies and how to fix it in calm, plain language, rather than in programmer-speak.
Generally speaking, bad error messages come in two varieties: The Too-Specific and the Too-General. Too-Specific errors are those errors I often see if I am using an open-source or crowd-sourced platform, such as FireFox. Because these platforms are designed to be used both by garden-variety users and by Power Users who can get into the code, find bugs and offer fixes, the errors you encounter tend to give a lot of information. This helps the Power Users, but when a normal user encounters something along these lines, it can make your brain explode. Unless you are a programmer, the only thing about this error users understand is System Error at the top of the box; the rest of it is not only indecipherable, but also fails to communicate what the user may have done to trigger the error or how to recover from it.
On the other end of the spectrum, you have the Too-General error. These types of errors are not as common as they were even five years ago, owing to vast usability improvements in programs like web browsers, but you still run into them from time to time. These are the errors that made you want to bash your head against the table because other than telling you there was an error, the message told you nothing else. Was the error caused by me? Was it something in the program? How serious is it? Can I recover from it? What are my next steps? You cannot answer any of these questions with an error message like this one.
The solution from a usability perspective comes somewhere between these two extremes. A good error message should give the user enough information to know exactly what happened. The message should be delivered in plain language, without codes or technical jargon, so as not to overwhelm average users. It should also specify what the user needs to do at this point to correct the error; my personal preference is also to indicate how serious the error is. Can I complete the operation I was attempting to do by changing something small, or did I just crash my OS? as an example. Errors like this score high on the usability side of things.
It would be remiss of me not to mention another attempt to help de-stress users who run into a certain type of error online: The dreaded 404 Error. This error was always frustrating to run into, because it normally happened when you were attempting to access a webpage which had the information you had been searching for for at least an hour, and yet the information was just gone! Poof! Vanished!
Some savvy web designers have started getting creative with the 404 error in an effort to relieve frustration experienced by the user. These efforts may or may not score highly in terms of usability, but they are very entertaining. Here are a few great examples!