I've been thinking about this a lot lately because it's bitten me in the behind a few times.

Think of the Windows User Account Control in Windows Vista (and to a lesser extent Windows 7). The idea is that when something that can break your machine happens (like malware trying to install or opening a system folder), the UAC pops up and makes sure that you're aware of what's going on.

As a power user, I get the UAC control a lot. To the point where I automatically dismiss it. So the one time where it could have saved me (a website was hacked and was installing a virus on my machine) I automatically clicked yes.

Another scenario on the Xbox, you get a lot of "are you sure you want to do this" prompts. Again I automatically accept those.

Well there was one time that I accepted it without thinking then saw "this will wipe your profile saves on all attached storage, do you really want to do this" as the dialog I just accepted went away. With the net result being that I lost a year's worth of game saves from my Xbox. Boxers in Fight Night, Racers in Need for Speed, Fully powered up warriors (and 60 hours of gameplay) in Blue Dragon were all gone because I had become so inundated with "are you sure" prompts that by the time I really needed to pay attention, I had been indoctrinated to ignore them (like how everyone automatically clicks accept on the EULA and Terms of Service dialogs).

Is it a matter of crying wolf? Or is there something more to it. How do I keep the user aware of important events without innundating them?

  • 18
    Mozilla Firefox has an interesting way of forcing you to think about confirming the installation of extensions: the "Install" button stays grayed out with the text "Install in...3" with an animated count-down. The user can become desensitized to this too, however (I certainly have). Commented Sep 5, 2013 at 22:07
  • 2
    There are some good answers here, but for a more in-depth look I highly recommend Alan Cooper's About Face 3: amzn.com/0470084111 It has a whole chapter "Alerts, Errors and Confirmation", and covers many of things mentioned below such as supporting deep undo/redo, hiding the ejector seat leaver, rethinking file saving etc.
    – Ergwun
    Commented Sep 6, 2013 at 1:28
  • 10
    @Jrop - that's not to force you to read it, it's to ensure that websites don't pop up the window as soon as your mouse pointer goes to click something in the same position as the install button.
    – detly
    Commented Sep 6, 2013 at 4:51
  • 2
    @detly Good point. Not to mention pressing enter in a text field when a completely unrelated message box pops up and steals focus - oh, is there a non-rant question about valid reasons to steal focus? I didn't find one, so here it is... Commented Sep 6, 2013 at 8:21
  • 3
    @TobiasKienzler - Focus stealing is the worst. The number of times I've typed my password without looking at the screen, only to realise I've typed it into a new window, in plain text, for all to see...
    – detly
    Commented Sep 6, 2013 at 11:59

12 Answers 12


Mostly it’s crying wolf. Ninety-nine percent of the time the user selects the command, that’s exactly what they mean to do, so they very quickly get in the habit of smacking the OK button without more than a glance at the message. Designers don’t help the situation often providing vague, incomplete, or jargony messages, so that if users do take the time to actually read them, they don’t get any helpful information to decide if they really should proceed or not. Instead, users are rewarded with just getting past them as fast as they can.

As for solutions:

Use warnings as little as possible. They should only appear for truly exceptional situations. If normal use of your app results in a message box, then your UI is wrong.

  • Rely more on making it clear what will happen before the user selects the command (e.g., clear labels in user’s language, dangerous controls spaced away from common controls). If deleting a profile also deletes saved games, then the screen should graphically show that a profile includes the saved games.

  • Make it possible to reverse any action at least as easily as it is to commit it. This can be through an Undo feature. If it’s easy to revert, you don’t need a warning. Don't delete the profile. Recycle it.

  • Make dangerous commands less dangerous so they don’t need a warning. Maybe you don’t want Select All to have the Ctrl-A accelerator in your app if users rarely need to select all and it can lead to accidentally deleting an entire document. Can we make it so that deleting a profile does not delete any saved games? Can we make deleting a saved game a separate operation?

Make the warning effective with a single glance. Even if you do it right and only have warnings when they are really necessary, users click-OK reflexes are so well-trained from other apps, you still have to assume they’re going to look at you warning only long enough to see how to get past it. You want to maximize the chance they get the key elements of the warning despite the users’ training.

  • The text should be as terse (but complete) as possible. Don’t say: “You are about to delete your profile for Boxer Craig Crusher, which will delete all saved games associated with this profile. Are you sure you really want to do this?” Say “Delete Craig Crusher and his saved games?”

  • Label the execution button with the action to commit (e.g., “Delete”), not simply “OK” or “Yes.” At least you can count on users looking at the button, and if they meant to hit “Copy,” they’ll see they’re wrong.

  • Consider giving each message a unique icon or picture to represent the consequences. A clear picture can be processed with a glance. Show graphically what will happen (e.g., Craig Crusher dissolving away). If what’s being affected can't be shown in its entirety parent window, then show it in the message box.

See my answer to Verification of Consequences for an example. I’ve more on dealing with the plague of message boxes at Of Dialogs and Detritus.

  • 12
    Another important point: make warnings fixable. If I get a warning each time that my widget is foobarred, and I have no idea why I should care or how to fix it, then I will ignore that warning.
    – MSalters
    Commented Sep 6, 2013 at 6:37
  • 2
    Microsoft is setting a very poor example here, because their common dialogs don't support setting text for the buttons. Gtk and Qt have better common dialogs where other buttons can be easily specified.
    – Jan Hudec
    Commented Sep 10, 2013 at 11:37
  • 6
    +1 If normal use of your app results in a message box, then your UI is wrong.
    – kmoe
    Commented Dec 16, 2014 at 17:53

In situations where consequences may be truly disastrous you may copy this idea from github:

enter image description here

Dangerous actions are marked (red bar in background), user is forced to read this box and it is verified as simply punching button is not enough. Note that using it for anything less than "nuke big collection of data" used once a year will result in furious users.

  • 14
    A great solution for the really disastrous options out there. Commented Sep 6, 2013 at 9:22
  • 2
    Anyway, a "anyway, the content of your repo was zipped & emailed to you" would be the extra mile in order to fully protect the users from their own errors (a.k.a. "making it fool proof" which I dislike because of the "fool" part). Kind of "undo".
    – Juan Lanus
    Commented Sep 10, 2013 at 21:18
  • 3
    @Juan Lanus - repository size may easily reach tens of megabytes, go into hundreds of megabytes or even reach gigabytes. But, yes adding some sort of "undo" would be even better (I have no idea why it was not done). Commented Sep 16, 2013 at 20:06
  • 2
    @Juan Lanus - I see potential problem of users learning that this action may be undone, than deleting giant repo of Fizzbuzz Enterprise or something similar and discovering that "since repository is larger than X GB it was deleted permanently. Muhahaha." Note also that issues, comments, pull requests etc are not part of git repository, and recreation of this is not trivial. Commented Sep 22, 2013 at 4:41
  • 1
    +1 for suggesting more advanced user interaction than just pressing a button. Many big MMOs like World of Warcraft or The Old Republic also have this approach: if you're trying to delete a character, you need to manually enter Delete to do so. if you want to delete any item that is above a certainq quality (like anything you get from a boss), you also need to confirm by manually typing Delete.
    – Nzall
    Commented Aug 7, 2014 at 9:51

To the question of:

How do I keep the user aware of important events without inundating them?

Make sure your updates are meaningful.

UAC, TOS', and EULA's are constantly skipped over because they don't provide meaningful content to their user. UAC, for many, is simply annoying - users feel that they shouldn't be warned every time they want to do something, even if it potentially breaks their computer. They want freedom, even if they regret the actions they take while being free to do so.

Similarly, TOC's and EULA's are skipped over because ain't nobody got time for that. The user is presented with a mass of text, and the only thing preventing them from the content they want is 25 minutes of reading legal parameters. They figure, "This is probably just legal stuff they're obligated to say, like this software's Nutrition Facts label.."

So what can be done from a UX point of view?

Find a meaningful way to convey what you need to, without bogging down your user and training them to auto-skip your important things. Microsoft could've done this with UAC by sub-classifying their UAC Alerts, and if it was specifically a virus, then disabling close for a few seconds when the window opens, and having gigantic type that says Hey, so you know, you're getting a virus.

EULA's and TOS' have, at least in recent years, been largely replaced with a check-box that simply states that "Yes, I've read your Terms of Service". They understand no one reads it whether it's in long-form or an abridged version, and have updated their approach accordingly.

The thing many companies fail to realize is that the format in which you update your user of new things is just as important as the potential content for the updates itself. It has to be packaged nicely for the user to want to read it – otherwise they auto-close, like you explained.

But that defeats the purpose.. right?

Not at all. As a UX Designer, I personally don't want my users to sit through 50 pages of boring legal text because it's boring legal text. Likewise, my users presumably don't want to read 50 pages of it. It's legally required that it's there, though. So it's my job as a UX Designer to make their updates be delivered in a form they care about, while giving them info I'm obligated to give them. By doing so, you create alerts they'll learn to care about.


download bmml source – Wireframes created with Balsamiq Mockups


The "Too Long; Didn't Read" version is to simply say the following:

  • Notifications to the user should be meaningful, simple, and convey the exact thing you want it to convey.
  • Don't go detail heavy at first, but provide a way to access the very detailed, legally-accepted version if they so choose.
  • Don't make it scary. Provide your information in a way that isn't threatening, but make notifications regarding threatening things (like viruses) stand way out from the proverbial crowd.
  • 10
    "Microsoft could've done this with UAC ... and having gigantic type that says Hey, so you know, you're getting a virus." This is a horrible example. If they were able to tell it was a virus the response would be "We blocked a virus from installing". Beyond that the predecessor of warning fatigue, the Windows messagebox, used to have 8 different icons; it's since been condensed to 4 (one which is deprecated) because the icons only added to user fatigue/confusion. Commented Sep 5, 2013 at 18:49
  • I disagree, Dan. At the moment, UAC pulls it's warnings by identifying certain types of action taken on higher and lower system levels. By adding even a SINGLE layer of analysis before passing a "Are you sure?" prompt, it could further classify beyond those 4 messages. By categorizing via icon/color, but adding simple and easy-to-understand messages, they could save user fatigue. "Do you authorize blahblah.." no one will read. "A virus is trying to install" puts the subject up front. That's the key.
    – Arman
    Commented Sep 6, 2013 at 16:13
  • 7
    Detected virus would be blocked without asking. Problem is in deciding whatever something that want to be installed is a legitimate software or a malicious one. Commented Sep 6, 2013 at 17:53
  • Which suggests that the actual function of UAC was to deflect responsibility from the system (which was too stupid to determine the actual harm of the action) to the user who wasn't given enough information to determine the effect of the action. A corollary is that the UAC would be completely ineffective, which in fact it turned out to be.
    – msw
    Commented Sep 7, 2013 at 2:09
  • 2
    It was supposed to cover situations where system is unable to discover that something is malicious action, but human is able to notice it - with the same data. Commented Sep 8, 2013 at 14:52

You are basically saying "How can I save the user from making bad decisions?" (In this case the bad decision of ignoring an important warning).

It's worth noting that this is the same impulse that led to all of those excessive warnings in the first place!

The answer is: you can't. If you try to prevent the users from freely choosing to make damaging decisions, all you will do is annoy everyone (I am going to throw my computer out a window the next time a program asks if I'm sure I want to exit!).

What you can do is make the interface as intuitive as possible so users know what they are doing in the first place. Warning messages are often a way of papering over bad design. (In your example, the problem was that there was a function that erased all of your saved information, and yet it wasn't immediately clear that it did this).

  • 2
    +1 for "how can I save the user from making bad decisions?" and "papering over bad design". Commented Sep 5, 2013 at 22:41
  • That last paragraph is the gold in the hills. Commented Sep 7, 2013 at 19:22

In some cases the best way to warn the user about dangerous actions is to... not warn them at all. Just do it, and notify them clearly and concisely what just happened. But then add an undo button, Gmail-style. Actually I lied, you don't want to "just do it", you want to appear to do it and delay the actual action until it's clear the user doesn't want to undo.

This can be the best of both worlds, the user that actually wants to do the action gets the instant feedback with no annoyance, and the user that does it accidentally panics for a second and then sees the undo option.

It obviously won't work with some UIs ("Oh you want to undo giving that virus root? Uhhh...") but the ones where it does work, it works great. With your XBox example, selecting the delete button could immediately show a notice All game save data permanently deleted. (Press Y to Undo) that persists until you leave the settings menu, and only then does the data actually get deleted.

It might add some complexity (what if the xbox crashes/loses power?) but an undo option probably worth it for the average case when it applies.

  • 1
    Press 'Y' to Undo? huh? :) Commented Sep 9, 2013 at 9:19
  • 3
    @nicodemus13 In the Xbox menus A is accept, B is cancel, and X or Y are used for secondary actions.
    – cgmb
    Commented Sep 9, 2013 at 23:51

An approach I have seen and liked is to break the flow of the application. Although for most things this is a bad UX, I think for potentially catastrophic or dangerous actions, it is sometimes a good idea.

For example, on console games generally the button at the bottom such is the accept or OK button.

enter image description here

So for wiping all data, as an example Y could be made the accept button. It would force the work UI flow to be broken enough and give the user time to read.

In a form, unusual controls can be used to force a delay as well, set the default button as cancel or force an additional step before the user can complete the action.

enter image description here

  • This is good advice, but it's worth noting that the convention of the bottom button being the accept/OK button is not global.
    – Kit Grose
    Commented Sep 11, 2013 at 0:34
  • 4
    I built a system once that had to let users make fairly catastrophic deletes from time to time. I broke their flow by making them confirm twice using random questions and changing the meaning of the answers (so "Yes" wasn't always the go-ahead button) and I made the default action cancel. It was annoying for the user, but much less annoying than having to admit to their manager that they'd wiped out days of work accidentally.
    – Joel Brown
    Commented Sep 16, 2013 at 1:02

In addition to the excellent response by @MichaelZuschlag, Linux uses an extra and effective approach (except Android, which implements a different method). When an action affects the system (e.g. installation of a new program, an upgrade of the core system, or a program upgrade from an unexpected source), the system asks for an administration password.

Newcomers from Windows are initially put off by this password prompt, but they quickly learn that the system prompts for the password only for dangerous actions and not for safer or run-of-the-mill ones. The operating system enforces this, so malware cannot bypass it.

That way, when you're asked for your password, you realise that it's important, so you stop and read the prompt.

  • 6
    The key in this case is not the method Linux uses. It is the fact that only actually important things are raised as an issue. Dialog warning boxes would be just as effective if they were only used for important things.
    – user31143
    Commented Sep 5, 2013 at 18:18
  • 3
    Paddy, if you're not running as an admin user in windows, UAC requires an admin username/password. If you're running as admin it only requires a Yes/No dialog response. Commented Sep 5, 2013 at 21:03
  • 1
    sudo caches the elevation privilege for a while in its default configuration, so your statement is not entirely true Commented Sep 6, 2013 at 8:39
  • 1
    @TobiasKienzler, at least in my version (Ubuntu), sudo does not catch the configuration between different applications or instances (for CLI, a single terminal tab is considered one instance). Perhaps this varies between distributions. Commented Sep 6, 2013 at 13:10
  • 3
    @dan1111 yes, I get your point. However, I have found myself clicking "Yes" on a dialogue where I was expecting a different question, only to realise (an instant too late) that it was an unusual authorisation request. Having to type a password would have eliminated that problem. Commented Sep 6, 2013 at 13:12

I think you answered your own question with your last paragraph. Systems that "nanny" the user with constant warnings, and give all types of messages equal visual weight, do so at their own peril.

Help your users cut through the noise and understand when a message truly requires their attention. You can do this by building their trust by tightly defining what constitutes a Destructive Action, and only strongly warn on those. Other messages (success, confirmation, and advisory) can be presented in a gentler, less intrusive fashion.

I assume you are asking this because you want some guiding principles for your own design work. Assume that most users are not experts who routinely void warranties. They get those destructive action messages probably a lot less than you do, and may not be as attenuated to them as you are. But the only way to know this is to watch them play / work / use their computer.

That said, the key to proper alerting is in having an ontology for your messages. When do you warn? When do you nudge? When do you confirm? If you define a destructive action too conservatively, you end up over-warning, and crying wolf, as you say. You also want to decide where you draw the line between protecting users from bona fide destructive actions, and protecting them from their own foolishness. Too much protecting and that built-in security becomes an obstacle that people wish they could turn off. It's one instance of the usability / security trade-off. Calibrate it, test it, and re-calibrate it until you hit the sweet spot.

  • RED WARNING = Your files will all be deleted unless you take action now!
  • YELLOW ADVISORY = Are you sure you want to delete that file?
  • GREEN CONFIRMATION = File saved successfully.

The user needs to be able to quickly discern success messages from nudges, and nudges from destructive action warnings. Once they learn your information hierarchy, they can confidently blow past the success messages without even reading them (because the visual presentation of the message tells them they have been successful) and hopefully actually read the advisories and true warnings, and take appropriate action.

  • 1
    Except in exceptional circumstances, "file saved successfully" and similar messages shouldn't pop up any kind of dialog at all. It just did exactly what I told it to, why do I have to dismiss a message saying that it was successful? Just let me keep doing my work! Indicate success by some other means, if it needs special indication at all. A status bar message or icon, a window being dismissed, a message (like this comment) showing up where it is expected, or whatever happens to be appropriate in that particular case. Flash something once or twice if you want to, but do so non-modally!
    – user
    Commented Sep 6, 2013 at 9:31
  • Yes, I agree that we should indicate importance of a message with the interaction style as well as choice of color and wording, and I am in full agreement that a "file saved successfully" can just fade in and fade out without the need to dismiss the message. Feedback = good, interruption = bad. Commented Sep 6, 2013 at 14:47

The accepted answer is great and has most of what I would have said, but I'd like to add the concept of using pre-selected categories to ensure minimum updates with full effectiveness.

In the case of windows UAC, it would be nice to be able to tell the computer "Let any app I have started run with it's own data in /program files, but if ANY program attempts to modify any data in /windows, I'd like a warning about it.

The Android OS does some of this categorization in that it requires each app to tell you what permissions it needs before it is installed.


do the test I did: create a logon script that shuts down the computer and add 2 confirmations: "do you want to shutdown the computer" with yes/no options. if user choose No means that it had read the message box. if clicks Yes, then add a second message box with the text "are you sure you want to shut down the computer?", again yes/no options. it's funny, over 95% of users called us saying that their computer it's not working. this test proved that we cannot trust users, therefore no admin rights for them! better: lock registry for writing. when you need, just unlock, then lock again. if someone asks to grant him admin rights, just say NO!

and you are right: "it is a matter of crying wolf"

  • This is interesting that 95% of the users will click yes on a dialog twice without truly reading it...but it goes with my experience as a power user. Commented Sep 11, 2013 at 16:22

There is absolutely not a single case when the message boxes are somehow needed. This was a huge mistake to put an element like this in all those GUI libraries for few reasons:

  • Extremely annoying.
  • Most of users just click the close button without reading.

Addressing your concern how to keep users informed about important events:

  1. Do not overrate an importance of the event (connection errors are not important, as well as timeouts are not).
  2. Use widget, which implements the folded event log (it must be closed by default).
  3. Notify users for the configurable amount of a time with a small blinking colored widget (it could be a small LED-like button in the tray or something like that) about new events in the log.
  4. Let the user decide an importance of the event. (This one is the most important, but it does not cancel item one).

You can also include a "Don't ask me again" checkbox on less serious diaglogs, e.g. "Are you sure you want to quit?"

  • 4
    That question shouldn't have been there from the very start... In general a "Remember my decision for the future" checkbox may be more sensible, though of course in your example that might result in a non-quittable application... Commented Sep 6, 2013 at 8:41
  • 3
    @TobiasKienzler Let alone when the application doesn't make it obvious how or even that you can change your mind later. That always makes me very wary of checking "remember my choice" when answering a prompt. A simple "To change this choice later, go into Tools - Settings - Remembered answers" or whatever would go a very long way, because it presents a clear way of backing out of the choice. Make it obvious. Even if 90% of the people don't read that text at all, those same 90% are probably unlikely to make use of "remember this" anyway.
    – user
    Commented Sep 6, 2013 at 9:36
  • @MichaelKjörling Indeed I think I encountered that positive improvement once. Though that as a tooltip on the checkbox might be nice, since the dialogue shouldn't be too bloated Commented Sep 6, 2013 at 10:45
  • 1
    @TobiasKienzler It could also be displayed when the checkbox is selected. Either way, I find myself wanting something like it time and again: make it obvious how to undo the choice when the choice is to save some setting.
    – user
    Commented Sep 6, 2013 at 12:23
  • Ugh. Why ask me even once if I'm sure I want to quit? If there is an actual issue with quitting, ask about that issue. e.g. "Do you want to save your file?". 99% of the time the "Don't ask me again" option indicates the question was never necessary in the first place.
    – user31143
    Commented Sep 20, 2013 at 10:35

Your Answer

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

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