How would you handle users who don't read dialog boxes?

Question

A recent article on Arstechnica discusses a recent study performed by Psychology Department of North Carolina State University, that showed users have a tendancy to do what ever it takes to get rid of a dialog box to get back to their task at hand. Most of them would click ok or yes, minimize the dialog, or close the dialog, regardless of the message being displayed. Some of the dialog boxes displayed were real, and some of them were fake (like those popups displayed by webpages posing as an antivirus warning). The response times would indicate that those users aren't really reading those dialog boxes.

So, knowing this, how would this effect your design, and what would you try to do about it (if anything)?

Answer 1

Immediately Steve Krug's book Don't Make Me Think comes to mind.

In the design of dialog boxes, status messages back to user, etc. it is good to use iconography and color hints as to what the words actually say.

So highlight error messages red, warnings yellow, etc.

Answer 2

Firstly the use of color and icons should help give the user some visual awareness of the severity of the issue, red to convey exceptional, yellow to convey a warning, and white to convey informational.

Secondly the use of verbs on your dialog buttons gives the users a sense of what they are telling the system to do even if they don't read the text of the dialog.

Lastly, if you are interested in looking into a completely different notification paradigm check out the Information Bar or Notification Bar that is implemented in Firefox and Internet Explorer. StackOverflow uses the same type of mechanism to notify users when they have gotten a new badge.

The Information Bar is non-obtrusive and stays at the top of the screen waiting for user attention. I think it's a great design metaphor.

Here are a couple of implementation tutorials:

• C#
• JavaScript

Here is Microsoft's guidance on dialog design, it touches on the Information Bar concept as well.

Answer 3

A couple of suggestions

1. Only use boxes when absolutely necessary.
2. Always set the default option to the least dangerous option

Answer 4

One thing you can do is have the Ok button disabled for 3 seconds.

Firefox does this when you install an extension.

Edit: Alright, some people find this annoying. I still think that about 1 second would be alright. It would suppress the instant-ok-clicking instinct that people (myself included) have, and force a double-take. Of course, even this will annoy people if your dialog is not something that they actually need to read.

Answer 5

I think you probably want to read this paper: "Impact of High-Intensity Negotiated-Style Interruptions on End-User Debugging", T. J. Robertson, Joseph Lawrance, and Margaret Burnett, Journal of Visual Languages and Computing 17(2), 187-202, April 2006.

It asked a similar question. The result was, let the user know you want their attention and then sit back and wait for the user to respond. Don't interrupt the user though, that's not what he or she wants.

Answer 6

First of all, stupid should hurt, but usually it doesn't so...

The next best thing is including an icon that tries to convey the severity of the issue. Some percentage of those who won't read might change their habit if the dialog's icon seems ominous. Some percentage won't read it regardless.

Answer 7

Often developers use modal dialog boxes simply because its easy to code them.

However, non-modal notifications are often more convenient for the user to deal with.

Answer 8

If you must use a dialog, put descriptive captions on the buttons within the dialog.

For example, instead of OK and Cancel buttons, have them say "Send Invoice" and "Go Back", or whatever is appropriate in the context of your dialog.

That way, the text is right under their cursor and they have a good chance of understanding.

OS X does this most of the time. Here's an example image.

Edit:

This is a better image, and I found it at the Apple Human Interface Guideline site, which is a great reference, and very readable. This document on that site is all about Dialogs.

Answer 9

I try to design applications to be robust in the face of accidents -- either slips (inadvertent operations, such as clicking in the wrong place) or mistakes (cognitive errors, such as clicking Ok vs. Cancel on a dialog). Some ways to do this are:

1. infinite (or at least multi-step) undo / redo
2. integrate documentation with the interface, via dynamic tooltips and other context-sensitive means of communication (One paper that is particularly relevant is about 'Surprise, Explain, Reward' (direct link: SER) -- using typical psychological responses to unexpected behavior to inform users)
3. Incorporate the state of the system into said documentation (use the current user's data as examples, and make the documentation concrete by using data that they can see right now)
4. Expect user error. If there's a chance that someone will try to write to a:\ when there isn't a disk in place, then implement a time-out so the system can fail gracefully, and prompt for another location. Save the data in memory until it's secure on disk, etc.

This boils down to two core things: (1) Program defensively, and (2) Keep the user as well informed as you can. If the system's interface is easy to use, and behaves according to their expectations then they are more likely to know which button to click when an annoying dialog appears.

I also try very, very hard to avoid anything modal, so users can ignore most dialogs I have to use, at least for a while (and when they really need to pay attention to them, they have enough information to know what to do with it).

It's impossible to make a system completely fool-proof, but I've found that the above techniques go a long way in the right direction. (and they have been incorporated in the systems used to develop Surprise Explain Reward and other tools that have been vetted by extensive user studies.)

Answer 10

The Lightbox modal dialog seems an effective technique in some cases (web 2.0 derivation, but can be implimented in other contexts).

One other point: if you can forgo a dialog box for an Undo function (Gmail for one championed this concept as standard webapp behaviour) that's something to consider.

Answer 11

Include a multiple choice quiz at the end of the dialog box, to which the user must select the answer that shows they really did read and understand the text. Randomly switch the order of the choices so they cannot always click the same one.

Answer 12

The Human Interface, by Jef Raskin is worth reading. Basically the dialog box is the last resort, and a sign of poor design. Most are unnecessary, and as you discovered are all ignored by users.

Why is there a dialog box? Solve that problem - don't ask users to confirm an operation, instead make it easy to undo the operation. Don't popup a dialog box announcing an error - do whatever recovery you're going to do anyway (or whatever is possible). Definitely don't show dialog boxes which have only one outcome ('OK' only boxes are the devil), present the information within the app unobtrusively.

Answer 13

A DNR episode comes to mind (I believe episode 338 "Mark Miller on the Science of Good UI") discusses this very topic. I think what is key to this whole discussion is that this is basic UI design taken too far. Where the modal was once an acceptable means of communication we now find that it has become programming faux pas. Users understand that 6 times out of 10 the information is not pertinent enough for them to worry about. As a result they treat all modals the same way -- learned helplessness. If a modal comes up and tells me that Application Error X occurred and all I can click is "OK" -- even when I don't think it is "OK" I learn a particular behavior. I assosciate modals with the idea that I probably can't do much about them, but if I click OK/Yes then I can get back to what I need.

So, Why is it still used? Perhaps developers have tried avoiding the fact that application development is becoming more than just a basic interface, and users require a fluid UI design -- old standbys are hard to give up...

I think the key here is to understand that good UI design now indicates that interruptions (to even the most novice computer user) are annoyances and we need to strive to have a seamless user experience where the focus of the application is the user -- not the needs of the application via prompting and error reporting -- don't allow a user to get into situations where they don't care.

Answer 14

One suggestion:

1. Don't use dialog boxes. Especially modal, OK/Cancel dialog boxes.

Sometimes that is hard... how do you handle opening a file? Sometimes it's easy... do you really need to warn the user that they are about to overwrite a file? Chances are, if I'm blindly clicking "OK", I'm not going heed any warnings whatsoever.

Answer 15

Lots of good advice above. I just want to add to the book recommendations - Joel Splosky's "User Interface Design for Programmers" book is worth reading:

http://www.amazon.com/User-Interface-Design-Programmers-Spolsky/dp/1893115941/ref=pd_bbs_sr_4?ie=UTF8&s=books&qid=1222233643&sr=8-4

Answer 16

Changing the wording and how the dialog works helps. For example, having OK/Cancel buttons tends to let users ignore most of the dialog. If you remove the normal buttons and replace these with wordier commands links, users are more likely to read each button because the 'quick, go away' option isn't available.

Answer 17

If you must use a dialog, reward the user with amusingly sympathetic or even satirical and very short explanatory text. If you occasionally hand out something hilariously scandalous they will read everything.

User is running dangerously low on common sense. Please remove this user and insert another one.

Answer 18

I call this the "autopilot" problem.

1. Do not use the OK, Cancel buttons on the bottom of the screen. Look at the way that Vista tries to force users to make a real decision.
2. Disable the buttons for a few seconds, display a "Time to think" timer/progressbar. So the user cannot click on autopilot. Users tend to find this very annoying.

Answer 19

Don't use confirmation (Are you sure? Yes/No), but use Undo.

Don't pop-up warnings that will are blocking, because users will try to get working again as fast as possible, disregarding the message and just clicking it away. Use something like the information bar from Internet Explorer, which is not blocking.

Answer 20

Wrong question. "How would you handle users" starts at the wrong end.

The correct question is "Given that dialogs distract users from the task at hand, what better alternatives exist?".

When working to achieve a goal or finish a task, we can distinguish three situations:

(1) The application comes to the conclusion that there is no action it can take which will make the user achieve the goal. Pop up a message, with one button to dismiss it. You don't care if the reader understands it, since the outcome doesn't matter anyway.

(2) There is only one action that you can take, or the alternatives are irrelevant to the user. Don't bother him at all.

(3) There are two or more ways of achieving the goal. Let the user choose between these. Do not formulate this as a yes/no question. (Vista offers this as a common dialog, to replace the message box.) If at all possible, do not make this an irreversible choice.

The exception to this rule is the situation where the user would expect a yes/no question. But really, if that is the case, then why isn't the question part of the normal workflow? Dialog boxes are outside the normal workflow.

Answer 21

You can avoid using dialog boxes alltogether! In some programs there's a minibuffer that shows errors and warnings. Along that, it may also ask you a thing, where you must type what you want to do. It is quite clean and nice solution, I tend to prefer it over a menubar.

But if you really must use dialog boxes, try this:

• One sentence per dialog only
• At most two or three buttons
• Make the text readable inside the dialog (bigger, black-on-white)
• Rather use one dialog than many small repeatedly (tip: listbox)

What do I think about dialog boxes? In nutshell: They are dumb and stupid things. Programs that use them get on my way and slows me down with their stupid meaningless questions. Also, often programs that use dialog boxes are rather dumb.

Answer 22

I have little patience with users who do not read what has taken me a lot of time and effort to develop: 1) the application 2) the instructions Aside from that, if you do not read and just do "whatever it takes" you are on your own. I state that up front. I design my applications to be as intuitive as possible and still there are people who will make support phone calls out of the blue, like a child blurting out in class when they shouldnt be. I have no tolerance for that. Read the manual, read the dialogs - the answers to 99% of the problems are right there.