Thanks to Gabriel Svennerberg and Sam K for this one - raised in a comment here.

I was fairly casual about alert boxes until a run of user tests where an alert box was put up to warn learners that if they left an online course at a particular point they would lose work they'd already done. Leaving aside the fact that that situation should probably never arise in the first place (! no poka-yoke there), we were very alarmed by what we saw.

Users basically clicked on that alert box in a completely random way, based on their prior experience of alert boxes in other software.

Only a smallish minority of users read the text of the alert box. Most just clicked something: either the button that kept them safely on the page, or the one that deleted their work, or the 'X' to close the dialogue. Most were bemused by whatever came next. Digging deeper, it seemed that many people just had a set action for 'error' boxes - click something to make it go away.

On that basis, how far do we go to avoid alert boxes?

  • 2
    Isn't the main problem in this example the safe default option not being made more prominent than the dangerous one? If the user is on auto pilot the design should bias them to making the safe choice.
    – tom
    Commented Apr 27, 2010 at 8:20
  • 1
    Related: What research is there suggesting modal dialogs are disruptive?
    – Zelda
    Commented Aug 10, 2012 at 15:19

11 Answers 11


I think a main reason of the overuse of alerts boxes is that they are so easy to implement. It's much harder to implement a forgiving user interface.

Alert boxes are bad for several reasons:

First of all, since they are modal by nature, they interrupt the users work flow and are therefor ill suited tasks that are performed regularly.

Secondly they are ineffective since, like Andrew already pointed out, users tend not to read them and just click something. If the system throws alerts all the time during normal tasks, the user eventually tends to ignore them and just habitually click “OK”. When he realizes that he’s deleted the wrong document, it’s already too late.

In my opinion alerts should be reserved for really critical events, like when you are about to perform an irreversible action that are not performed regularly (e.g. deleting a database). Otherwise there are much better ways of designing things.

  • Agreed. Key bit of the answer: 'there are much better ways of designing things'. Tricky to find those ways sometimes, especially good error prevention (as well as error recovery), but that's the goal. One hesitation though: the designer knows when an action is critical or high risk, and that's when we put an alert in. But the user might not recognize the seriousness of the situation they're in, and, crucially, the alert box that pops up exists in the context of every other alert box they've encountered across all the software they use, not just the one's we've carefully placed in ours.
    – Andrew Merryweather
    Commented Oct 15, 2009 at 21:20
  • Agreed! An alert box is used to draw users' attention, so it will interrupt users' actions and should be used carefully. I like the idea that alerts should be showed for critical actions.
    – Lookchin
    Commented Jan 25, 2013 at 6:13

Users basically clicked on that alert box in a completely random way, based on their prior experience of alert boxes in other software. ... On that basis, how far do we go to avoid alert boxes?

The question almost answers itself: Never use alert boxes.

Modal alert and dialog boxes place a barrier in front of the user. Of course they respond by dismissing the barrier. Often they don't read the warnings and end up doing something they regret.

Here's an alternative:

  • For informative messages that do not require action, present the message unobtrusively inline (as this site does).
  • Confirmation messages should be eliminated as much as possible. Instead of confirming an operation beforehand, simply carry it out and let the user undo it later.
  • Questions that the user must answer should be presented within the page in an ordinary form. Since this does not present a dismissable pop-up, it does not trigger the "Click anything to make it go away" reflex.
  • 1
    I think you've nailed it. A simple answer, but of course it throws up some great little design challenges.
    – Andrew Merryweather
    Commented Oct 16, 2009 at 10:30
  • And those great little design challenges are what makes our job so much fun. :) Commented Nov 13, 2011 at 23:55


When it comes to alert boxes, they are perfectly fine to use. You just need to know when to, and when to not use them. Knowing when it easy, just follow this simple logic:

Never use a warning, when what you mean is undo.

This logic is covered in an in depth article, that you can read here.

By the sounds of it, you are correctly using an alert box, because you are warning your audience that they're about to loose their information. That said, there are still questions to be asked:

  1. Can you detect if a person has changed anything? If so, you can eliminate the alert if there isn't any information to loose.
  2. Are people not reading, or not understanding your alert? If they're not reading, and mindlessly clicking the the "OK" button, don't use "OK." Rename it, "Quit Application, and loose what I've done." If they're not understanding your alert, try different language.

Of course, retest your changes. What you'll most likely find is you'll never get everyone to read an alert box, no mater what you do. But, if you can get some percentage you're happy with, that's all you need.



The real problem is that alert boxes are implemented too often and without any thought given to the user. Check out the alert I got when I had this comment field in focus (but nothing typed!) and I tried to close this window: http://www.flickr.com/photos/jonesabi/4033266787/

OK/CANCEL? Seriously?

  • 1
    Lovely juxtaposition :)
    – Andrew Merryweather
    Commented Oct 22, 2009 at 7:08

Hmm. Very interesting, Andrew. Shows why assumption without evidence is generally bad.

My argument about using alert boxes was really based on the familiarity aspect of them, but from what you're saying that appears to be more of a negative than a positive. Familiarity breeds apathy, I suppose.

I guess an additional question is then whether to use the single "OK" button alert as opposed to the "OK"/"Cancel" confirmation alert. One of the biggest drawbacks of the latter is that you can't change the text of the buttons and more often than not, "OK" and "Cancel" are misleading and irrelevant.

Great question, though. If we don't use alerts (and I guess I'm meaning exclusively JavaScript 'alert's), what other options are there, and how do they compare from a usability perspective?

  • That issue of having to use Ok/Cancel on button labels for default JavaScript alerts has been a real bugbear for me. As a kind of interim solution while we get better at error recovery (the web apps I work on are not great at 'undo' yet) we've been trying to design bespoke dialogues with good explanatory labels for each option. It doesn't eliminate the 'don't read the text of the alert' problem, but labels like 'Save work'/'Delete work and exit' are an improvement on 'Ok'/'Cancel'.
    – Andrew Merryweather
    Commented Oct 15, 2009 at 21:26

Simply: an alert is exactly that - an alert. They have there place, but they are also heavily over used sometimes.

I think one of the main problems with alert boxes are that they're just plain ugly, and not very customisable in most cases. Designers/ developers will invariably come up with a 'custom' solution, different for every solution/ application so there's no consistency which is another massive problem users face.

(And that goes for all languages/ technologies)


Alerts are also bad because they prevent tasks from being fully automated in large batches. Let's say your program or app does some Task X (that takes 30 seconds) on input Y. Let's say now your user wants to perform Task X for input Y for 100 values of Y. If Task X has no alert boxes, then the user can set up the task to run across 100 inputs and she user comes back 50 minutes later to find all 100 tasks completed. But if Task X involves popping up an alert box (at any point in the 30 seconds of mostly automated work) then the computer has to wait for the user and the user has to watch and oversee a task that is now asking the user the same question 100 times. A better design would be to set up an option/preference and save it, or at least have one of those boxes with a checkbox that says "Don't ask this again."

  • 1
    Definitely agree that 'Don't ask this again' needs to be a part of good use of alerts and dialogues - streamlining for the expert/repeat user.
    – Andrew Merryweather
    Commented Oct 15, 2009 at 21:33

Yes to all the avoiding ABs stuff, specially by means of better design.

Now, in case you decide to use one, then it must be designed.

The most basic AB has three parts: title, text, and button(s).

I use titles that communicate the meaning of the AB, like "Trash changes?", like that, so it can be grokked at once.

In the text I explain more, like "You changed this document, and now you are about to discard those changes. Click 'OK' to discard, 'cancel' to return to safe."

The labeling of the buttons is important. The "do it" button, the primary one, must be aligned with the title. If the title is "drop it" then the primary button must be "yes" or "OK".

With this kind of design I try to shorten the time the user needs to be aware of the outcome of accepting the ABs offering.

  • Yes, definitely agree that careful alignment of button labels and title helps reduce errors. I guess the danger still lies in the number of people who click on something without having read any screen text at all!
    – Andrew Merryweather
    Commented Oct 26, 2009 at 13:14
  • I disagree with an important aspect of your answer: the labeling of the buttons. In my opinion, using OK, Yes, No or similar nondescript button labels is a no-no. Instead, label the button with the actual action. In your example, "Discard changes" and "cancel". That also removes the need for the explanation of what button does what.
    – André
    Commented Jan 22, 2013 at 16:29

i try to avoid them as much as possible making what will happen next clear from the previous interaction. just ask your self is a alert box a smooth experience? no its interruptive and "alerty" hahah.

also why does the data have to be lost. there are ways of storing data even if the person reloads or navigates away. i have when forms loose data within my current session.

just my opinion :)


I agree that they should be avoided at all costs; quite frankly, most users have come to learn to just ignore them.

However, what about those times when you absolutely need to make sure they've seen AND read the message? On one of my projects, users need to be alerted of upcoming downtime... usually, they'll get an email (which gets ignored), as well as a clear message on the dashboard when logging in (which they also ignore).

One thought was to have a modal window pop up when they first log in, but again, they're likely to just click to close it. For this particular application, it's crucial that they're made aware of it since it adversely affects their job.

What then? Do I include a 5-second timer before any "dismiss" button appears? Yes, that will likely piss off the user, but wouldn't it be effective, for those few times where it's really needed?


If strictly necessary, one may eventually go into create a couple of alert messages in applications. however, you should bear in mind an issue which is the information density you want to put into your application.

You may want to have an app that gives a lot of feedback of utilization to the user, or an app which doesn't do such a thing, and has a smaller information flux.

Anyway, I should advise that having zones In the application where there is more information, zones that have less informations, zones that are in between, and keeping a timeline of events in cache that allows to adjust the displayed information according to the user input, the number of times the application has been used, etc., can be a nice strategy. so playing with density of ui elements in accordance with user input analytics

Your Answer

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