ArticlesA very important part of software usability is the quality of the error messages. When things start to go wrong, error messages can make the difference between the user realising their mistake and quickly correcting it, or getting frustrated and confused.
Unfortunately, error messages are often produced by coders rather than the user-interface designers. Coders have other priorities than carefully wording an error message.
One short, cryptic error message in our application was causing a lot of confusion; it was causing a large number of calls to our help-desk. I decided it was time to fix the problem.
I sat down, and carefully reworded the error message. The new version explained the problem that had been encountered. It explained how it came to be that this problem had occurred. It explained step-by-step what was required to fix the situation. It did it in English that had been carefully written for clarity and had been peer-reviewed.
I had, in my own little way, made my users’ world an easier place to live in.
Shortly after the release, I received an email from a user that contained a screen-shot of the brand-new easy-to-understand error message, and a short request: “I got this error. What do I do now?”
I almost started sobbing.
Comment by Pupeno on January 10, 2007
There are users that read error and users that don’t. The difference would be easily calculated by comparing how many calls the tech support got after you improved the error.
For that one user that sent you an email (only one user) just copy and paste the set of steps… maybe then he/she will realize that errors, messages, signs are there to be read.
Comment by Mark on January 10, 2007
Actually, the best UI design practice is thinking “the user never makes mistakes”. Error messages should be reserved for extreme cases in which the app can’t interpret what the user wanted to do. It’s hard to tell without knowing the details, but if it’s a problem that is frequently reproduced by users and the steps to correct it can be listed, then the problem most likely can be corrected silently by the app itself instead of asking the user to do it.
Example: in Windows try dragging and dropping a document over a running app on the taskbar, you will get a dialog explaining that you should not drag a document over there. The computer knows that I wan’t to do but it won’t allow me. Microsoft should a. implement the taskbar to do something (most likely open the document) or b. change the cursor to a “not allowed” cursor to hint that the action is impossible.
Comment by Mark on January 10, 2007
Ahem, don’t want to sound like a smart-ass here, but from what I’ve seen from the captcha’s placement, its error message, and the confirmation of success without offering a link back to the entry to see my comment in place, I’d say your problem could be definitely could be easily be solved by good UI design.
Comment by Julian on January 10, 2007
Mark,
I agree with you in principle – although I would word the practice slightly differently. It is not the the user “never makes mistakes” as much as “don’t give the user the opportunity to make mistakes”.
As you hinted, sometimes it is not possible. In this particular situation, the solution required a physical action to be taken by the user, which wasn’t something that could be solved by software.
As for the captcha placement – oh dear. I am afraid I have never seen the captcha facility on OddThinking. I am using a SpamKarma, and it only displays the captcha request on borderline cases, where it can’t decide whether it is spam or not. It knows my IP address, and never doubts my email. Mea culpa. I clearly will have to do some more testing; I have been overall impressed with the plugin, so I assumed it was doing a reasonable job here too. Sorry.
Comment by Mark on January 10, 2007
“I’d say your problem could be definitely could be easily be solved by good UI design.” — I’ll take those words back as I now see you know your stuff. Nonetheless it would be very interesting to see the actual problem!
Comment by Monkeyget on January 10, 2007
Maybe your message was overly long (at least it’s what it looks like reading your post) and the user didn’t bother reading all that text.
Comment by Julian on January 10, 2007
Monkeyget,
Yes, that is a trap that I sometimes fall into.
I try to ensure that the important part is in the first sentence, so they can decide whether to read the rest or just ignore the error and continue..
But surely, even if an error message is a long one and you are not a strong reader, it is easier to read through it than to take screen shot and ask someone else to read it for you.
Inevitably, the email I sent back was longer than the error message. Inevitably, the language wasn’t as tight or as clear. I didn’t have the time or the resources to spend on one support email that I could spend on getting the error message “right” the first time.
Comment by sTew on January 12, 2007
Well…
The user is not there to figure out how your software works but rather to complete a particular task at hand. When confronted with an error message, it disrupts the completion of the task.
Had your message read “We have an error, click on this button/link to fix/find out how to fix it” and you may have different feedback.