How Do You Get Users To Read Error Messages?
A BOFH writes "The longer I do desktop support, the more it becomes obvious that my users don't read anything that appears on their screen. Instead, they memorize a series of buttons to press to get whatever result they want and if anything unexpected happens, they're completely lost. Error logs help a lot, but they have their limits. I've been toying with a few ideas, but I don't know if any of them will work and I was hoping my fellow Slashdotters could point me in the right direction. For example, I was thinking about creating icons or logos to identify specific errors. They might not remember that an error is about 'uninitialized data' but they might be more able to remember that they got the 'puppy error' if I showed a puppy picture next to the error message. Or for times when finding images is too time consuming, you could create simple logos from letters, numbers, symbols, colors, or shapes, so you could have the 'red 5' error or 'blue square' error (or any combination of those elements). I've even wondered if it would be possible to expand that to cover the other senses, for example, playing a unique sound with the error. Unfortunately, haptic and olfactory feedback aren't readily available. I like to think that my users would remember the error that caused them to get a swift kick in the balls. And if they forgot it anyhow, I could always help them reproduce it. Does anyone else have experience with ideas like these? Did it work?"
Just put a timer on the buttons that won't let them click it for 10 seconds... but ultimately you can't fix stupid.
Do yourself a favour and produce a one-click tool that collects all the info that you need (logfiles, version numbers, registry listings) and sends it to you. If you can make it 0-click, even better.
If you were blocking sigs, you wouldn't have to read this.
Users have already trouble copy-pasting error message text into a mail (or reading it aloud on the phone), so how the hell are they going to do it with a sound or a smell? Well, the sound, they could still record it, and attach the recording to the mail, but you can be sure that the recording will be spoiled by the perp's coworker loudly sneezing or coughing midway through. After all, lusers are not afraid of sending in screenshots of error messages half-hidden by other windows either.
No, I think the problem is not the messages (textual messages should be the easiest to deal with, especially when asking for support via mail), but rather the users. And to fix those, you just need a baseball bat...
I had done something very similar, but I kept it very simple for troubleshooting.
3 colours: red, amber, green
3 shapes: circle, square, triangle
Another idea I was toying with was to substitute traffic signs: ie. stop, yield, caution, etc.. but I found that people are used to ignoring those.
With my setup, it gave me 9 distinct error levels (more if I used them in combination), but 9 was good enough for me to track down most problems.
Shapes:
Circle - Bad Input (i.e. data field entry)
Square - Bad Output (i.e. printer jam)
Triangle - Back-end (db/php/html, etc..)
Red, amber, Green = error levels
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
It's not an error. Errors prevent you from continuing. The only thing approaching an error is the little box telling you there's a problem. That is solved by the user clicking "OK".
The entire way errors are handled is wrong. I don't know what the solution is but I very much doubt it's a simple modification to the current fundamentally flawed system.
I have been wondering about this for 30 years. End users are not interested in learning how the computer software works, except for how it lets them do their job. On-screen messages, manuals, fax-back systems, wiki pages, they don't care. What they want is to pick up the phone, make a call, and have someone tell them what to do. At first, I thought it was them being lazy. However, I now think it is closer to why programmers don't like to be interrupted in the middle of a task. The user has a mental model built up of their task, and they don't want to risk losing it while they search for information on an error. Making a phone call, and having someone else walk them through the problem solving means they can maintain their task in "main memory". For them, it is more efficient.
Why, without your clothes, you're naked, Miss Dudley!
I know users whose definition of unexpected is that they have to copy text from a program they've never used before. You couldn't handle that with a script, but how these people have a job not requiring a broom is an eternal mystery.
I don't think UI designers should try to pander to them either, because it will make programs unbearable for everyone else.
My Sig: SEGV
Stop pushing the inadequacies of the program on the users. If you come across the error, then log it. Why are you relying on a person to sit there and read back to you something that could just as easily be written to a file that they could send to you or read directly.
Every day I have to fire up a Microsoft Access database program to clock in.
Every day the first thing it does is pop up a dialog box that says something like, "Only run this if you trust it".
I just hit OK.
It's not my problem if it works right or not.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
Amiga had this right. Use a little humor with your messages, it may diffuse the anger and get some sympathy.
As a corrallary: Reduce the number of errors/confirmation dialogs they see on a regular basis. If they regularly have to click-past dialogs, they get trained to do that without reading them. If the presence of a dialog means 'call helpdesk, and read the dialog to them', they are more likely to pay attention to it.
Make seeing a dialog an exceptional case, not a normal case.
'Sensible' is a curse word.
Number one answer would be to make error messages that are actually useful.
Here's an error I got recently. It's a pretty common error in our SAP* system: "Error Code: -1 Error Desciption: Code: K/101. Error occurred in derivation rule. See long text." (Please note that there is no long text.)
Here's another recent error message I encountered. Is this helpful?
You have either entered an invalid Member ID, an invalid PIN, or your User Account is locked. Please validate that you are entering the correct member ID and PIN and try to log in again. "
Translation: when you did the mandatory password change (required every 90 days), you entered a password that contained the } character. Although the rules say you must include symbol characters, we didn't mean that symbol character.
And dozens of other equally useless ones.
--
*"SAP" is not actually an acronym. It is the word used to describe the customers who have been persuaded to buy this software.
http://www.geoffreylandis.com
It does not work that way, NEVER! BECAUSE all damn apps are just random hex dumps of errors. When i started using Linux i was in for a major surprise: No annoying random popups, and all apps would actually GIVE me actual errors such as "can't find libPORN.h" or "Does not have acces", or similar. The point is that Windows users by default have seen to many popups, and too many of the errors where JUST a gigantic bunch of a hex dump without any real message. Now, instead of trying to get the people to read it, get a underlaying system to Email you the errors instead. Because you shall NEVER bother the end users unless its a good thing.
I am not really sure what you accomplish by disabling the software for 15 minutes. It sounds to me that if the person ignores your error message they get a 15 minute break.
One thing IT people often forget is that their job is to make the other employee's jobs easier and more productive. This means solving problems without getting in the way of the work that actually makes the company money.
Morpheus, God of Dreams.
"uninitialized data" is meaningless. It's something only a programmer would understand.
Instead tell the user what *he* did wrong and tell him how to correct the situation.
"No recipient address given. Please enter the the e-mail address of the recipient and try again".
This is your sig. There are thousands more, but this one is yours.
Users have been conditioned to simply click away message boxes as quickly as possible and get on with their lives.
A Windows computer is constantly popping up boxes that get in your way. Sometimes it's just to inform you that a wireless network was found... Other times it's asking for confirmation for something... Other times it's a warning... Sometimes it's an error...
Folks don't evaluate what the message says, they just make it go away.
You can put all the puppies and red numbers and blue squares as you want... They're still going to click it away just as quick as they can.
You could alleviate this to a certain degree by taking away their ability to clear the error message. Put in an error code somewhere, along with a phone number for technical support, and no way to close the box. They'll call you and you can have them read off whatever you need. Then you can tell them whatever bizarre combination of keys will actually close the box.
A better solution would be to simply write a log of the error message when the box is generated, then you don't need to rely on the user to do much of anything.
"Work is the curse of the drinking classes." -Oscar Wilde
There should be no errors. Period. Your program should not allow errors.
So what is a program supposed to do when the hardware it talks to fails or is not plugged in? Or when the network resource it requires is not available? Shuffle its feet and hem and haw and hope the user won't notice?
Anyone who says "there should be no errors" doesn't know how the word "error" is used in computing. That there should be no BUGS may be a formally realizable goal (at least that's what my functional programmer friends tell me) but let me ask you: when was the last time you drove a car that had no error notifications on the dashboard? No idiot lights, no oil pressure gauge, no fuel gauge, nothing but a speedometer?
Never, right? That's because all machines have a physical component whose state is sometimes unable to fulfill user requirements, and we need to communicate that state to users. We call those communications "error messages" in the software world, and they cover everything from "out of memory" to "printer on fire."
On another note, I like the ball-kicking idea, but my users are mostly female, so it won't work. Recently I've had a bunch of complaints about missing hardware because they are clicking through the dialog that detects that hardware is missing, and then complaining when the main UI comes up and tells them there is no hardware connected. They never remember they've clicked through because they are so used to simply clicking OK on any dialog that comes up, a phenomenon that has gotten much worse in the past few years.
Blasphemy is a human right. Blasphemophobia kills.
One of my peeves is users complaining about "jargon". Error messages are not jargon, proper names for peripherals are not jargon. If I ask you if your ethernet cable is plugged into your network card, that is not jargon. And yet users will tell me "why do you guys always use fancy jargon that I don't understand?".
Never argue with a man carrying a water buffalo
I think the core problem is, perhaps, with the mindset of most software developers. They think logically and prefer a computer to immediately notify them about exactly what's wrong, as soon as an issue arises. They're also accustomed to the traditional way errors are reported, and feel most comfortable making things stick to "tried and true" methods.
The typical user, however, doesn't see any of that as advantageous or even sensible.
Take the example you mentioned, where your users were clicking through a dialog that detects hardware is missing, and then complaining about the main UI coming up and telling them the hardware is not connected. To a user, they've got a specific process they want the machine to complete, and they'd like to go through the required steps they memorized to do the process without any unexpected interruptions in the middle of the input. Such interruptions lead to them "clicking through" the boxes without reading them.
So what would improve this? I think users would like computers to ignore error conditions until they're done with all input related to performing an operation, for starters. Don't want them to click through a warning dialog? Ok ... then don't present them with it until the end. (EG. If a printer is disconnected, either notify them of this state BEFORE they even begin inputting anything into the portion of your application that generates printed reports, or hold off until they're finished and they click "print". At that point, give them a friendly error telling them the printer seems to be disconnected, and their print job will complete automatically, once they re-attach it.)
On the same note, *friendly* error messages are key, too. I can't begin to count the number of times I've received an error dialog box in an application that told me nothing useful. I know something just went wrong in the program, but that's about it. Some apps like to dump a bunch of numerical error codes at the user, with expectations that somehow, this data will get forwarded on to one of the programmers who actually understands it. In reality? There's a near 0% chance of that ever happening! The developers at most companies are insulated from the end-users by layers of "customer service and support" people. And what about apps no longer being actively supported at all? Their developers have moved on and probably don't even REMEMBER what those numerical error codes mean anymore if you COULD contact them!
It's no wonder users just "click through" the error boxes these days! They're conditioned to expect the messages do nothing to help them.
jargon
NOUN
1. specialist language: language that is used by a group, profession, or culture, especially when the words and phrases are not understood or used by other people "typesetters' jargon"
2. unintelligible language: pretentious or meaningless language ( disapproving ) "Cut the jargon and get to your point."
____________________________________
Your definition and the dictionary's definition of Jargon do not agree. A network cable is just a cable of some sort to most end users. They don't recongnize it for its function, just that it plugs into thier comuter the same as the monitor cable, the power cable, etc. It's up to you to define the cable for them using terms they will understand. That is part of your role as a support person. Not bothering with this aspect of your job makes you bad at your job.
My favorite, from the old days, was when I was trying to talk a reluctant secretary through some minor DOS voodoo. I asked if anything was on the screen. She said no. I asked, "do you mean to say that it is completely black, with no letters anywhere?" Well, no, of course not - it just said C:\DOS>
While we all like to laugh at stupid user tricks, the real problem is a lack of communication. In your example, you wanted to know what was on the screen and it seemed reasonable to ask if anything was on the screen; to the secretary, her answer was correct because , for here, something on the screen means "I have something I have opened" on the screen.
One thing I have learned is don't think the other person understood what you said - their frame of reference may be different and you need to consider that when communicating.
I'm a consultant - I convert gibberish into cash-flow.
You absolutely can.
Sorry, no.
It's very easy: discipline people and if they keep doing it, fire them.
That doesn't fix the stupid, it just moves it somewhere else. And how, exactly, does this work when the stupid is in management?
It'll probably only take one person before everyone else starts paying more attention.
Bullshit. The stupid people will continue to be stupid, and blame you for not making their problems go away.
Oh lighten up you twat, this is one of the few instances that joke actually works.
Canada: The US's more awesome sibling.
Absolutely. Asking the right questions the right way is key. For example, rather than asking if anything is on the screen (a yes/no question, doesn't require as much thought), you ask "What does the screen show right now?" (which actually requires some thought.)
Telling a user that you're stupid isn't such a good idea either ... I would simply say something like "No, of course not. But I deal with users who have varying levels of familiarity with computers, and so I've learned to pace my instructions so that even novice users can easily follow them. Would you prefer me to speed up a bit?" That way you're neither telling the user that they're stupid nor saying that you are, you're "blaming" the "problem" on some other (potentially non-existent) person.
The karma from funny is a lie.
https://www.eff.org/https-everywhere
I like a challenge...
define the cable for them using terms they will understand. That is part of your role as a support person.
Okay, so using nothing but text, please describe the concise difference between:
- An ethernet port
On the back/side of your computer you will see two holes that look like spots to plug in a phone cord. There'll be a little one and a big one. The big one is called an "ethernet" or "network" port, or if you want the fancy term, an RJ-45 connector, but we wont' be using that term again anywhere in this call...
- An ethernet cable
You'll find a cord or wire - it's pretty thick and has a big plug on each end. The plugs look like phone plugs, but larger. This is your "ethernet" or "network" cable.
- A telephone/fax port
actually this one you really don't have to go out of your way to describe as most people have experience with this one. So look for the spot that looks like a good place to plug in a phone cord.
- A telephone/fax cable
This is another one where people have a frame of reference so it doesn't take a description really. Look for the phone cable.
- A USB port
Hi - we need to find your USB port on your computer. It will look like a flat rectangle and there may be a bunch on the front and back of the computer. It's usually the place you plug your iPod in when you connect it to your computer.
- A USB cable
USB cables ... look for the wire that has a flat rectangle on one end, it may have all sorts of different sized things on the other end and we're not going to worry about that now. On the flat end, there should be an arrow and a couple of other funny looking symbols. There ya go - you have the right cable.
And is there anything else I can help you with, today? Your old telephone tech support people (not seen very often nowadays) are used to walking complete newbies or people who are scared they're going to break things through plugging things in, turning it on and then editing configuration files, usually while not at a computer themselves.