56

If your intended audience is nontechnical you find yourself at a severe risk that your users will plain ignore the carefully worded error messages, either staring in shock at them, calling and yelling at your support staff or simply ignore and/or close them.

I'm wondering what good practices you recommend for getting the users to actually read your error messages instead of disposing of them. Now I know some basics such as:

  • Short precise wording, possibly with a link or button to a detailed explanation.
  • Provide an example of what to do to rectify the error (e.g. "Unable to connect to the server. Please check your Internet connection.").
Improve this question
1
  • Make them meaningful - and if possible, useful. You can't force them to read it, but you can shape their behaviour.
    – David Clarke
    Apr 26, 2013 at 7:50

14 Answers 14

Reset to default
45

The book About Face 3 has some good advice. The paramount of which is to design the software to eliminate the need for error dialogs. In cases where that isn't possible, the authors recommend:

  • Make an error dialog polite, illuminating, and helpful. (Remember that the error message is actually the software reporting it's inability to perform, not the user's inability to enter valid data, for example)
  • Illuminate the problem, giving relevant information the user needs to make a plan to solve the program's problem
  • Offer to implement at least one suggested solution (my perspective: on Windows, take advantage of the built-in Windows Troubleshooting Platform, even though implementing it can be maddening :))

By far, the biggest take-away is to work very hard to avoid error messages altogether. Whether that's by implementing an Undo feature, or by offering alternative UI or inputs when an error condition occurs, or something else altogether.

Improve this answer
5
  • 51
    I'm reminded of the story of the Microsoft usability test in which an error message was displayed saying, "There is a $50 bill taped to the bottom of your chair." There was. It was still there at the end of the day.
    – Joel Spolsky
    Aug 16, 2010 at 21:01
  • @Joel There have been lots of tests with such a statement. It's not about people ignoring error messages. It's about people ignoring most of the text at all. [to be continued]
    – naugtur
    Aug 18, 2010 at 7:52
  • 5
    [continuation] There was this experiment where people who considered themselves lucky and unlucky were given a newspaper and they were paid 50$ to find a piece of information there. There was a large message "Stop searching and show this message to the test staff and get 300$" in the middle of the newsaper. The "unlucky" people were so focused on finding the information worth 50$ that they didn't spot the message. People nowadays read faster than they actually can...
    – naugtur
    Aug 18, 2010 at 7:56
  • 10
    @Joel there's also been one company which put in their EULA "We'll give 1000 dollars to the first person who calls us about this". It took like 3 thousand downloads and four months to get one person to notice that.
    – Mircea Chirea
    Aug 20, 2010 at 7:08
  • 4
    @iconiK I'm surprised anybody noticed it at all. There's a vast difference between an error dialog and an EULA!
    – Bennett McElwee
    Nov 23, 2011 at 8:54
15

You will always have a significant percentage of users who ignores many or all error messages. Even when they call support, have the error message in front of them and claim to have read it, they may very well still not have assimilated the content of the message. You should therefore try very hard to avoid having to put up an error dialog.

In addition to the advice given in About Face 3 (see Aaron Lerch's answer), it is a good idea to log all messages in such a way that they can be inspected afterwards. Don't rely on the user to know what the error message said, or even which button they pressed to get rid of the dialog box.

Improve this answer
4
  • 3
    +1 to logging at that detail. We've begun logging specially-tagged messages that trace a user's "movements" through the application so we can piece it back together again post-mortem. (If we had built metrics like this from the start for usage stats we could've used that, but we don't have that.)
    – Aaron Lerch
    Aug 16, 2010 at 20:58
  • I think Jeff Atwood wrote a Coding Horror blog entry about how impossible it is to get people to read error dialogs.
    – JesperE
    Aug 16, 2010 at 21:03
  • 1
    you are correct: goo.gl/8R6e
    – Mircea Chirea
    Aug 20, 2010 at 7:11
  • There's a handy problem steps recorder with windows 7 (and other version, IIRC). It's logging with nicer output :).
    – David Clarke
    Apr 26, 2013 at 7:53
6

If the users are non-technical then I would suggest one of two approaches:

  1. Only give them contact information to talk to someone. Basically remove the opportunity for them to even try to fix the problem because if they're not skilled enough to follow instructions, no matter how easy you make them, don't bother given them to them. Give them a 1-800 help number or clickable email or something.

  2. If you really must give them instructions then they need to be non-technical (aka written by your Mother, assuming your Mother is non-technical). Even the example you give "Unable to connect to server. Please check your Internet connection." might be too technical for the casual home user. How do I check my Internet connection? What is my internet connection? Remember, these are people that call the computer the "machine" and the monitor the "tv". Show them pictures, explain it in simple terms, etc. It's best to get someone who knows nothing about computers, if you're going to go this route, the sample documentation or error information you're planning on presenting and see if they understand it (I call this the Mother-In-Law test, if she can understand it, anyone can).

Improve this answer
1
  • 5
    As a technical user who often gets called in to help non-technical users, please provide enough information that a technical user can help them. Even if it's just a unique error code that we can get them to read to us (eventually) and then we can google. I use one particularly bad piece that reports all errors as "please call support, during working hours, in a timezone far far away, via a toll number that we'll take 45 minutes to answer"
    – Colin Coghill
    Sep 2, 2010 at 4:41
5

Location, Location, Location!

Make sure the error message is in a location that on one hand doesn't disturb the work flow but on the other, is easily noticed.

If the message is in middle of the screen and it block the access to the main form the user will close it right away probably without reading it, But if it doesn't yell out at all then the user may not even notice.

Improve this answer
1
  • The problem is that if it's not modal and it's a critical error users will call you with "doesn't work", instead of some who will say they have a strange error message.
    – Mircea Chirea
    Aug 16, 2010 at 20:58
5

To get people to read the important message you have in mind, you must first search the application for all the worthless messages, "Contact your administrator (who doesn't actually exist)!" and remove them or replace them with honest information. Once the noise has been removed from the message stream, it will be months before the user base will notice that the noise to message ratio has improved to the point where it is useful to read messages again.

Improve this answer
1
  • If they use several programs on a regular basis, they may never notice. But if they're on the same program all day at work? That'll do it. Eventually. Probably.
    – David Clarke
    Apr 26, 2013 at 7:54
4

(Looks as some of what I have to say here was answered by others before I posted -- some good info above, particularly Mr. Lerch.)

I think the unfortunate quick answer is "They won't." Similarly to the phenomenon of users owning product manuals but refusing to open them, a sudden, surprising, out-of-context (well, to the base user at least) message is going to be sudden, surprising, and out-of-context.

My inherit pessimism aside, I've found anecdotal success with the spirit of your given suggestions. WRT the first point, I agree with "short" but not as much "precise." The non-technical user is going to have issues with any error message. A "precise" message even more so, because the non-technical user needs not less information, but more (i.e., needs a bit of education) to actually understand what happened.

As an example, in the second bullet point, the non-technical user is going to have issues with the first part of your sample message.

  • What is it connecting to?
  • What server?
  • Why is it unable?
  • Did I do something wrong?
  • Did the software do something wrong?

Some or all of these questions are going to run through their head before they really get around to comprehending the suggested response. When they regain their composure and read the second part, they'll have another bunch of questions about how to check their internet connection. Some will interpret it as a modem or router issue and power-cycle that whole stack (no joke).

A bunch of this isn't really solvable in the error message; people have a level of computer literacy and your application probably won't have a signifcant impact on that. But if you were to

  • Provide first as simple a sentence you can explaining why they're seeing the message. 5-7 words.
  • Use simple, conversational language to explain in a bit more detail.
  • Offer (if it's the site's fault) an appology
  • Find a clever way to tell them not to panic
  • Ensure them things will get better

you may make the experience a bit more pleasant.

Note, the last few are easy to get wrong and end up sounding patronizing, so be cautious and test against some friends first.

Improve this answer
2
  • 1
    I have better success renaming the “server” as the “Main computer”. Users know that that “main computer” must remain on at all times. Then their own boxes can’t connect to the "main computer” then there’s something wrong with it. It sounds silly but the change from “Server” to “Main” helped a lot.
    – Martin Marconcini
    Aug 17, 2010 at 14:31
  • 1
    I would be surprised if "main computer" wasn't more often interpreted as the user's own terminal (i.e. client-side machine) when the reader should be thinking about the server-side machine. Further, I would never assume users know anything about server-side architecture, let alone up-time policy. For the case given by the OP, I might try: << [Firefox] is unable to connect to the Web site. <br> We think your computer might not be connected to the Internet. Please check if your computer is connected to the Internet, then refresh this page. <br> [The HTTP error code/response] >>
    – Matthew
    Aug 17, 2010 at 23:03
3

Make them relevant, concise, plain English, and located in a location not far from where the user is looking. Explain what happened and why it happened, but without too much verbiage. Finally, test or prototype the error states of your application just as well as other parts. We often forget and just have users walk through a process before we've built in all our error handling, and that leaves out validating a critical, possibly frustrating part of the experience.

Visually, make them stand out from other elements of the interface. Animation can help to create awareness; the Yellow Fade Technique is a great example of that.

Improve this answer
1
  • Relevant concise english is great. For native english speakers. There's some evidence that ESL - even highly fluent ones - are better at ignoring negative information and feedback in a second language. The best example (but not the most relevant) is swearing in another language. It doesn't have the same impact when someone swears at you in your second language - it doesn't have the same impact. Colours are better (but still not great), because they're not as regionally, linguistically or culturally diversified.
    – David Clarke
    Apr 26, 2013 at 7:56
2

Much of the best advice has already been submitted. I want to add that error messaging should be in line with the tone of the rest of the interface content. http://www.visual-ii.com/, which has a very conversational, slightly nerdy feel and whose homepage banner reads "Uncomplexification", has created a 404 error page in line with its slightly nerdy base: http://www.visual-ii.com/404.

Improve this answer
2

For unhandled exception type errors, which are rare but fatal when running the application, we came up with an error dialog which has three buttons:

  • 'Copy to Clipboard'. This copies the error details to the clipboard as text. The assumption is that the user will then use this to either email tech support or to paste into Notepad.
  • 'Send Error Report'. Sends the error details to tech support via email. This is the default button.
  • 'Close'. Close the dialog. This button is intentionally disabled for 10 seconds, or until the user clicks one of the above actions. The countdown is shown on the button's label.

As a safeguard, we also log the error message to a local text file, in case the user doesn't perform any action, which can then be inspected by tech support at a later time.

Improve this answer
1

There's tons of research showing that many non-technical end-users will ask for help from someone next to them, or technical support, rather than trying to solve problems themselves. That's human nature, and I'm not, sure we're ever going to get around that. But error messages have a bad reputation among non-technical users that we need to push past.

In addition to the points you mentioned above, make sure that your error message is:

  • Clearly visible. If it's critical, the user should be required to interact with the message before resuming interaction with the application.
  • Written in a friendly, casual tone, with non-technical language. Eg: Check out Firefox's messages.
  • Provide a concise but clear description of the problem, and why it occurred.
  • Provide clear directions for fixing the problem and a link to the starting place (if possible).
  • Unavoidable. It's way better to prevent the user error from occurring than trying to to write an effective error message.
Improve this answer
1

When an application give error messages that are useful in helping me solve the problem I read them. If an application(or vendor) has a reputation for having error messages that are not useful I quit reading them.

Improve this answer
1

Make it NOT look like an error message.

Don't use alerts or anything that You have to close with a button. Dispay errors in a static space reserved for that purpose (see webapps, CMS admin panels etc.)

Use simple and funny language.

Instead of "internal server error 500" try "Oops. Looks like we didn't expect that input. You might want to go back and see if You put something unusual in the form."

Instead of "error initializing the device" try "We couldn't use your [device, eg. GPRS modem]. Is everything ok with it? Check it and see what's in the configuration."

Improve this answer
1

Use an animated shrinking lightbox effect that focuses attention on the error message, along with any relevant portion of the display. Have text that says "(Click to here to remove error message)" instead of a button.

If you want them to send you data on the error, even with their inputs, says so. Use the word "need". "Here is data about this error that we need. Some of it may personally refer to you. Please click -->here<-- to send it to us."

Improve this answer
0

One of the most effective means to display an error alert is:

  1. Place the error note next to the element that the user can interact with to perform the correction
  2. Scroll the page to focus on the element and the error note
  3. provide a short animation (movement of the error note box) to draw the user's attention when the page is already centered on the problem area (e.g. short forms)

This orients the user to the corrective action in a helpful and non-threatening, but also insistent, manner.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.