How to get users to pay attention to problems?

Question

We occasionally need to notify users about warnings or problems. But often times, especially if it's a common problem, users will just dismiss the warning and continue. Often times users won't even remember seeing the warning, but we check their logs and see that several were displayed. So, how do you get users to pay attention when you're trying to tell them something important?

This isn't as simple as forcing users to resolve all problems before allowing them to save. They often need to save data that isn't strictly okay by our business rules for various reasons (usually for problems that can't be solved right away, or at all).

We've got a better warning/error handling system in mind that I think will help a lot, but I want to see what others have done.

Answer 1

The quality of your warning will not prevent users from submitting invalid data. If you allow invalid data to be submitted, it will be.

If you have data that must be submitted to a rules system, then that data must be valid before it is submitted. However, allowing users to save their work is a separate issue. You should allow users to save their work, then submit the data to the rules engine when it is valid.

Answer 2

I quite like the firefox method when installing plugins: The ok button is disabled and displays a countdown for 5 seconds. After that the use can choose to ignore it.

Answer 3

For web applications, the alert() and confirm() javascript methods, while somewhat basic, achieve the effect of either preventing users from doing something or making sure that they clearly agree to something that they have been warned about.

For other situations, where the action will not cause considerable disruption in the business processes, we often display a small warning box at the top of the page after, say, a form is submitted.

For example, our applications require location validation in several places (valid city/state/zip).

• If the location is absolutely critical, we will make it required on the form.

• If the location is required for some aspects of the application, we will use the confirm() to make sure they understand that they will not be able to use certain features without a valid location.

• In some cases, we use a default location. In that case, we provide the message/warning box at the top of the next page indicating that a default location is being used.

Answer 4

I must admit that I too often click on "OK" or whatever I'm conditioned to do for a dialog to go away without thinking. Usually this occurs when there are just too many of them.

Without claiming to be a psychologist of any kind, I think it is natural to pay attention to unusual things and filter away repetetive things.
With that in mind it is maybe worth considering to make less important dialogues less intrusive so that the real important ones get more attention.

I think toaster messages and the way google handles messages in it's online apps are real nice examples of how to notifiy a user of something inessential.

--EDIT--
Now that I re-read my post, I remember reading this in "Don't Make Me Think". A brilliant little book (few tens of pages) that's full of nice and easy to understand usability things. Somewhat focused on online usability, but defenatly applyable in offline applications too.

Answer 5

If you want users to pay attention to warnings, use them in moderation!

The big problem with the UAC in Vista is that people are getting so many notifications, that they stop reading who is exactly requesting access to what, they just give permission without thinking.

Another example is the delete confirmation in explorer when sending files to the recycle bin. I got so used to just hitting 'Ok' immediately after pressing 'delete', that I missed the fact that the dialog was telling me that the file would not be moved to the bin, but deleted immediately, for whatever reason.

My personal fix: I disabled the delete confirmation for the recycle bin. If something can not be moved to the bin, I still get a message, and this time I know that it might be important, so I pay attention.

Conclusion: Don't spam the user with messages, or the important warnings will get lost in the noise.

Answer 6

Though I never got around to implementing this at a previous site, I wanted to create a custom dialog box where users would have to check a box stating that they have read and acknowledged the message (and then log that response). This was for an ISO-xxxx company so this kind of bureaucracy was a logical response to these types of mistakes.

My other, much more sinister, idea was to make "No" or "Cancel" the default options. Eventually they would get the Tab-Enter keystrokes down pat and then you would just switch it back.

Answer 7

The fundamental problem is that users don't like to read, they just want to be left alone to do their work :).

The best way to combat this is the following:

• Don't pop up a window unless absolutely necessary
• If you do, make the error or warning message as short and succinct as you possibly can

Long error/warning messages simply won't get read. The user will get to about the fifth word and think "this is taking too much time, I just want to get back to work".

Answer 8

I've found that if you're producing log messages for your own use (even if that use directly benefits the users themselves), the only way to get users to report problems is to have the application do it for them.

In the case of dealing with user input that might be wrong, have you considered using something like the red squigglies used by spell checking or some kind of highlighting of the problem areas as the user does their work? Most users have been trained to ignore dialogs by using buggy software, but that kind of message might make it clear that the error is the user's to fix.

Answer 9

Do you have a good idea why each of the exceptional situations occurs? What do you try to achieve with each of these messages:

• make user review the data for obvious typos or mistakes

• make someone else to review the data at a later stage when more information is available

• inform this user and anyone else looking at the data at a later stage about any assumptions made

• make sure user understands the consequences of their actions

Can any of these goals be achieved more effectively in a different way?

Some ideas (none of them automatically qualify as a silver bullet):

• Keep messages short and relevant, exclude any language that does not contribute additional info (such as "please" etc), tell users what is expected of them (i.e. instead of "Post code is empty" use "Enter post code".).

• Use language that is understood by the users, always give sufficient information, try to be as specific as possible.

• Use different looking messages for different types of warnings and errors (use font, colour, imaging, possibly animation and sound).

• Revisit the entire process, so that someone has to process any info submitted with warnings later on.

• Visualise warnings the next time info brought to the screen (i.e. highlight problematic areas) so that they can be resolved later, when more info is available.

• Add a sign off to the warnings, for instance request a user to enter their password each time they need to dismiss a warning.

• Make actions undo-able, so you don't really need the warnings

Answer 10

Break the system!

It has honestly been my experience that if you don't want an end user to do something without explicitly understanding it, stop them from doing it...

As seriously anoying as the whole "Windows Error/warning Messages" gets, I never take notice until a program tells me I can't do something... then I am forced to ask myself "Why Not"

Time to google the answer... or RTFM

I know that it is not always feasible to use this approach, but if you can... they will listen!

Answer 11

My advice boils down to three things.

1. Reevaluate what you think is important for the user to know.
2. Don't be lazy and ask the user to resolve what your program can resolve for itself.
3. Don't interrupt what the user is doing with stupid (and yes, they are stupid) messages.

If you have a form with required data, then color-code the field as red or highlight it with an asterisk to indicate it's required. Disable the "OK" or "Confirm" button until they fill out all required fields.

For fields with incomplete or inconsistent data, bring up a tooltip or color-code the field so the user knows that something may be wrong. You could also display the list of warnings prominently somewhere on your form. But don't stop the data entry. You'll just frustrate and anger your users.

Answer 12

I like programs that hint that there's a problem while ignoring it as long as possible - which sounds very like what you're striving for. One thing I've been thinking about (but vaguely, since I haven't had a use for it) is putting a status indicator for errors/warnings (a bit like the omnipresent throbber of a web-browser, but for errors). This icon would change state, a bit like a traffic light, to show that the program has problems that will have to be addressed sooner or later - perhaps yellow for warnings if the problem with the data could be corrected later and isn't going to cause any major problems, red for any problem that is going to have to be fixed before they complete the current job (for form data, that would mean the whole transaction, not the current form). Obviously the colours wouldn't be enough, there would have to be some support for colour-blind people, but you get the idea. Clicking the indicator would bring up a list of the problems (and perhaps explanations as to why that is a problem - so that people can point out when the code's assumptions are unhelpful or wrong), and selecting a problem would allow you to jump to the field where it can be fixed.

One thing you should probably do, whatever method you go with in the end, is to look through your warnings and work out whether they're actually necessary. I've seen far too many programs that warn me about perfectly reasonable input that is then accepted, or warn me about the usual behaviour of the program. That's the sort of thing that helps condition people to click through warnings. If you have logs of the warnings, you might start there - Why are people clicking through them? They might be conditioned, or it might be that there genuinely isn't a problem, and someone hasn't told you that things have changed.

Answer 13

This is what we've got planned. Essentially, create something Bugzilla-ish for storing these errors/warnings/whatever. But it also goes hand in hand with some of the other answers.

Instead of using simple MessageBox, display warnings/errors in a Visual Studio-like error window. As long as there are problems, they'll be displayed in this window.

If the data is saved, save all warnings/errors to the database. Now anyone can see what the current issues are - bonus! Also, those problems can be loaded from the database instead of detecting them in the app all the time, which will help a lot - some problems are not trivial to detect.

Allow users to perform several actions, like:

• Acknowledge the problem, so it is no longer displayed.
• Assign the problem to another user
• Flag the problem as "not really a problem"
• Set a "must be solved by" date
• (probably others, the design hasn't been fully thought out yet)

Log all of these actions to the database, so we have accountability

That's it in a nutshell. Now problems stick around, so they're in the users faces until they're solved. The problems can be tracked, so we can tell where the ball was dropped if we get bit. I hope it works!

Answer 14

Dont try to solve with programming. See if you can change the data input process.

Answer 15

Use colors and icons.

Green - everything is ok (or confirmation something happened as expected)

Yellow - Warning. You user may or may not want to look into the issue

Red - Error. Something that requires user interaction to resolve.

I would also suggest (as others have on this thread) to use sparingly.