Friday, April 5, 2013
E is for Error Messages
Translation: I've screwed up and you've just lost your afternoon's work.
Usually followed by that smug little "OK".
No, it's flippin' well not OK!
As an application developer, the best thing to do is to make sure these little beauties don't happen in the first place, of course. But, equally of course, computers will screw up from time to time, and when they do, the least you can do is make sure they do so gracefully.
NO - to the cryptic techno-babble that the average end user won't even begin to comprehend.
NO - the end user will not want to debug the code. Don't even go there.
NO - the end user should not be left in limbo wondering what they should do next, or panicking that they've single-handedly brought the company system to its knees.
Things you can do
If possible, notify the help desk - behind the scenes - and log the technical details of the error somewhere a technical support person can get at them. The previous company I worked for used these measures very successfully. Often, by the time the user reported trouble, we were already working on a solution.
Keep the mumbo jumbo out of the visible message and instead tell the user what they should be doing next. Don't just leave them hanging. If you need them to stop work and report it, say so. If it's OK to log back in again and resume work, say so.
These are all talking about where the application chokes out of control. Then there's a whole class of errors that the end user will trip up over in the normal course of their work. Typing the wrong thing into a field, for example. These things should be detected by the application and the user informed in a way that is helpful and meaningful. Don't just spit out "Invalid input," say why it's not valid and what is expected instead.
Going the extra mile in handling errors will pay dividends in user satisfaction, and the extra effort in design and programming will repay you handsomely in the workload on your help desk.