Bugbears
Nothing gets me (or anyone else I have worked with) more wound up than unhelpful error messages, or even worse error codes! For that matter I get wound up (because I think I can do better) with any error messages at all. Here's the rational, using a day to day example:
RESTAURANT SCENARIO - You walk into a restaurant and site down. The waiter appears and says, "What would you like to order, sir?" To which you respond, "I would like the spaghetti bolognese, with extra parmesan and some garlic." Here are some potential responses when the spaghetti has run out:
- No Response - blank stare - a system crash when everything hangs
- "No" - the equivalent of an undecipherable error code, only a complete geek would NOT be offended, but instead look it up on the internet or a FAQ
- "We have run out of spaghetti" - a typical response found by most software, it tells you the problem in a rather terse manner that leaves you feeling frustrated
- "I am very sorry sir, but we have run out of spaghetti" - slightly better technique used by some websites, which leave you with a warmer feeling, but hell what do you do next?
- "I am very sorry sir, but we have run out of spaghetti, perhaps you would like to try the lasagne, which is equally delicious." - not only does this describe the problem but gives the customer an option (or two)
- "I am very sorry sir, but we have run out of spaghetti, we have more arriving tomorrow, perhaps you would like to try the lasagne, which is equally delicious." - not only does this describe the problem but gives the customer an option (or two) and shows the customer that the problem is being resolved
Of these, responses 5 or 6 are best, but software typically uses 3 or 4 and sometimes 2 (1 is typically outside our control). I have created 6 potential responses, but many more can be generated when pondering the following questions:
Does the user know an error has occured? Does the user know what the error is? Does the user know why the error has occured? Is the response user friendly? Does the user know what options are available? Does the user know how the problem will be resolved? Who is expected to resolve the problem, the user or the software? How is the message communicated? And, Is the user happy with the outcome?
This is one hell of a lot of stuff to think about for a simple error, but without it users will get frustrated, angry and stressed. This is BAD!!!
Simple Steps to reduce stress:
- Use good coding practices/conventions to control errors/exceptional behaviour and validate input properly
- Think about the a user's experience (be polite)
- Give users options
- Give users confidence that the error is a one-off (or very rare) and can be resolved
- Resolve the error with as little disruption to the user as possible
- gather feedback (in a non-intrusive way - you are now asking the user to do something when the software has died)
Some simple examples of where small changes make big differences.
www.petrolprices.com - in their forms they have textboxes that validate your entries immediately and put a bright green tick at the end. This saves unhelpful page refreshes where you then have to scan back through your web page to find the incorrect field entry.
Microsoft Feedback Gathering System - its optional, but at least it empowers users so they thinnk they can do something (if only a little)
Password reminder services - how annoyed would you be if you forgot your password and there was no option to get a reminder email!
Anyhow, without going on forever, think about the user, resolve the problem with as little hassle to the user as is feasible and ensure it doesn't happen again - You Bad Boy!
2 Comments:
You forgot a whole family of error codes in the out of spag. bol. example:
Response 0.5: No Spag Bol. Reason: Unexpected spoon on the table.
Good call, I may have to adjust the spag bog model to fit this category in. No doubt I have missed other categories as well!!
Post a Comment
<< Home