How would you handle users who don't read dial

Question

A recent article on Ars Technica discusses a recent study performed by the Psychology Department of North Carolina State University, that showed users have a tendency to do whatever 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

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 2

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 3

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 4

A couple of suggestions

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

Answer 5

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.

Answer 6

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.