How to get users to read error messages?

Question

If you program for a nontechnical audience, you find yourself at a high risk that users will not read your carefully worded and enlightening error messages, but just click on the first button available with a shrug of frustration.

So, I'm wondering what good practices you can recommend to help users actually read your error message, instead of simply waiving it aside. Ideas I can think of would fall along the lines of:

• Formatting of course help; maybe a simple, short message, with a "learn more" button that leads to the longer, more detailed error message
• Have all error messages link to some section of the user guide (somewhat difficult to achieve)
• Just don't issue error messages, simply refuse to perform the task (a somewhat "Apple" way of handling user input)

Edit: the audience I have in mind is a rather broad user base that doesn't use the software too often and is not captive (i.e., no in-house software or narrow community). A more generic form of this question was asked on slashdot, so you may want to check there for some of the answers.

Answer 1

One good tip I've learned is that you should write a dialog box like a newspaper article. Not in the size-sense, but in the importance-sense. Let me explain.

You should write the most important things to read, first, and provide more detailed information second.

In other words, this is no good:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

Instead, change the order:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

This way, the user can read just as much as he wants, or bothers, and still have an idea about what's being asked.

Answer 2

We told users their manager had been contacted (which was a lie). It worked a little too well and had to be removed.

Answer 3

Well, to answer your question directly: Don't have your programmers write your error messages. If you follow this one piece of advice, you'd save, cumulatively, thousands of hours of user angst and productivity and millions of dollars in technical support costs.

The real goal, however, should be to design your application so users can't make mistakes. Don't let them take actions that lead to error massages and require them to back up. As a simple example, in a web form that requires all its fields to be filled in, instead of popping up an error message when users click on the Send button, don't enable the Send button until all the field contain valid content. It means more work on the back side, but it results in a better user experience.

Of course, that's a bit of an ideal world. Sometimes, program errors are unavoidable. When they do occur, you need to provide clear, complete, and useful information, and most importantly, don't expose the system to user and don't blame users for their actions.

A good error message should contain:

1. What the problem is and why it happened.
2. How to resolve the problem.

One of the worst things you can do is simply pass system error messages through to users. For example, when your Java program throws an exception, don't simply pass the programmer-ese up to the UI and expose it to the user. Catch it, and have a clear message created by your user assistance developer that you can present to your user.

I was lucky enough, on my last job, to work with a team of programmer who wouldn't think of writing their own error messages. Any time they found themselves in a situation where one was required and the program couldn't be designed to avoid it (often because of limited resources), they always came to me, explained what they needed, and let me create an error message that was clear and followed company style. If that was the default mindset of every programmer, the computing world would be a far, far better place.

Answer 4

Less errors

If an application throws vomit at you on a regular basis, you become immune to it, and errors become irritating background muzak. If an error is a rare event, it will garner more attention.

Quosh anything which isn't a major deal, throw out all those warnings, find ways of understanding user intent, take out the decisions wherever possible. I have a few apps which I continue to streamline in this way. Developers see every error as important, but this is not true from a user perspective. Look for the users' common response to a problem and capture that, deploy that as your response.

If you do need to raise an error: short, concise, low terror factor, no exclamation marks. Paragraphs are fail.

There's no silver bullet, but you need to socially engineer to make errors important.

Answer 5

In my opinion and experience, it's the power users, who do not read error messages. The nontechnical audience I know reads every message on the screen most carefully and the problem at this point mostly is: They don't understand it.

This point may be the cause of your experience, because at some point they will stop reading them, because "they don't understand it anyway", so your task is easy:

Make the error message as easy to understand as possible and keep the technical part under the hood.

For example I transfer a message like this:

ORA-00237: snapshot operation disallowed: control file newly created Cause: An attempt to invoke cfileMakeAndUseSnapshot with a currently mounted control file that was newly created with CREATE CONTROLFILE was made. Action: Mount a current control file and retry the operation.

to something like:

This step could not be processed due to momentary problems with the database. Please contact (your admin|the helpdesk|anyone who can contact the developer or admin to solve the problem). Sorry for the inconvenience.

Answer 6

I read a candidate for the most horrific solution on slashdot:

We have found that the only way to make users take responsibility for errors is to give them a penalty for forcing the error to go away. For starters, where possible, the error wont actually close for them unless we enter an admin password to make it go away, and if they reboot to get rid of it (Task Manager is disabled on all client PC's) the machine will not open the application that crashed for 15 minutes. Of course, this all depends on the type of users you are dealing with, as more technically adept users wouldnt accept this kind of system, but after trying for literally YEARS to make users take responsibility for crashes and making sure the IT department is aware of them in order to fix the issue before it gets too hard to manage, these are the only steps that worked. Now, all of our end users are aware that if they ignore errors, they are going to suffer for it themselves.