There was a very interesting discussion on Slashdot the other day about writing good, memorable error messages. The question was basically: how do you get the user’s attention so they will remember the error instead of blindly clicking OK to get past it? Developers are tired of getting a call saying that an app isn’t working, but no more details. Worse still, users complain without the specifics, somehow thinking that saying “it keeps crashing” will help.
What it seems to come down to is that users are fairly immune to error messages. They often won’t actually see a message in front of them since they are conditioned to ignore them. Basically, if you are interrupting your users they will be annoyed and simply dismiss the message so they can keep going. It’s pretty common to hear “you need to click OK twice when you save – I don’t know why.” As developers we want to scream “read the message!” We wouldn’t show a message if it wasn’t important.
But is that really true? Let’s think about that a bit. If an exception occurs and we display a message box what do we hope to gain by it? The user doesn’t really care about what happened. Either you work around the error, or the user needs to stop everything while something resolves itself (e.g. network outage).
The worst thing to do is to ask a user for an error message when they call the help desk. The error will already be gone at that point unless it keeps popping up. Remember that the first instinctive action was to dismiss the dialog. The user doesn’t want to call the help desk. The user doesn’t have time to call the help desk! The automatic response is to click OK and try again. Telling a user to reproduce an error is also a sure way to cause upset!
The Slashdot discussion mentioned creative ideas like using colors/shapes/images. Perhaps the user would be able to say “it was the blue circle error” or “it was the dancing penguins” easier than “it was error #0800BADC: File permission error.” The consensus, however, was that such solutions didn’t really help. To the extent that a user will even remember such a message, this doesn’t convey any specific information. A red square might signify file access error, but without a path and specific error how does that help in troubleshooting?
The bottom line seems to be that error messages are a losing proposition. You need to do everything in your power to prevent error conditions from blocking the user. Obviously, simply avoiding errors isn’t possible (no matter what you might tell your clients!). Instead, you may need to be creative about dealing with unexpected issues.
Continued in part 2…
Link: http://ask.slashdot.org/story/10/03/01/132219/How-Do-You-Get-Users-To-Read-Error-Messages
Posted Friday, March 5th, 2010 at 11:09 am by Arian Kulp
921 views
[...] Better error messages – Part 1 (Arian T. Kulp) [...]