We're working on an internal business app, and throughout the process the users have been very involved in all aspects of the design. They have explained their workflow, terminology, etc. and the app models that as closely as possible, with their input at every step.

Most actions in the app can be undone, but there's one action that (per the users' instructions) can't be undone without going into the database and manually changing data. In order to confirm this action, the user has to click "yes" on a modal alert. Alerts are used very rarely in the app; there's only one other action that will bring about an alert. Neither action is performed very frequently.

However, the users are still somehow occasionally clicking on the wrong action and confirming their choice in the alert (presumably ignoring the text on it). What's the best way to remedy this?

The text in the alert is a bit long, so we're looking at making it shorter and more to the point, and maybe renaming the buttons so they aren't just yes/no, but we don't know if that's enough. Is there some other way to draw the users' attention and make them really realize what they're doing? Are there proven ways to reduce errors like this?

Our ultimate solution: For now, we're focusing on changing the text and appearance of the alert dialog, as per Matt Lavoie's and André's answers. We made the text shorter and more to the point, added a caution icon and a clear statement that the action can't be undone, and changed the buttons to say what they'll do and not just yes/no.

We also changed the text on the button that launches the action to be red and in caps (all the other button texts are in black and just first letter capitalized).

Finally we made the entire background of the app go bright red when the alert dialog comes up. It's quite jarring, so the users should definitely notice it.

We mentioned the changes we're making to the users, and they were totally in favor of it. If these aren't sufficient we'll add additional input requirements to the alert, as in Andrew Leach's and JeffH's answers.

  • An additional idea we had is to require a double click for this action, whereas all the other actions are single click. Would that be helpful or confusing?
    – Maltiriel
    Commented Jun 25, 2012 at 22:12
  • 3
    Naturally the best option is to make every action undoable, but if that's not possible/feasible, there are two main things you can do: label the button something explicit like "Delete permanently" as opposed to something like "OK", and if the action occurs during a wizard or similar be sure to move that button away from the previous "Continue" button so a user doesn't inadvertently click the same spot a few times and trigger your permanent delete.
    – Kit Grose
    Commented Jun 26, 2012 at 4:30
  • 1
    you could perhaps delay the execute for x amount of minutes and add an undo button somewhere, people generally realize that they shouldn't have done something immediately after doing it.
    – Dani
    Commented Jun 26, 2012 at 7:23
  • @Dani unfortunately that hasn't been the case for us. There are two actions that can be taken, one is like flagging and the other is like archiving (it's kind of complicated business logic, but all according to how the users say things should work). The user archived instead of flagged and took several weeks to realize it.
    – Maltiriel
    Commented Jun 26, 2012 at 15:30
  • So I'm not sure which answer to choose... We're using a combination of different suggestions, and there are several techniques here that would be really useful. Should I just accept the answer with the most up-votes in that case?
    – Maltiriel
    Commented Jun 27, 2012 at 14:22

10 Answers 10


You could try using color and/or icons to differentiate the more critical actions from the less serious ones. If there is a series of buttons next to each other that are all grey and then one that is red, I will be more likely to differentiate that from the others.


download bmml source – Wireframes created with Balsamiq Mockups

Maybe even in big bold red text right in the modal you could put "This action may not be undone" right above the continue button.


download bmml source

Worst case scenario you can pull the old "Type 'DELETE' into the box to permanently delete this item" and not enable the continue button until they type delete (or whatever the action is) into a text box. In that case they cant really deny that they didn't know what they were doing.

  • 5
    I'm not sure it's such a good idea to go out of your way to draw the users attention TOWARDS the most destructive option. That's like having a big red button with 'Do Not Touch' written on it - asking for trouble.
    – JonW
    Commented Jun 25, 2012 at 20:57
  • 3
    @JonW oh come on, they've got the big red button on the wall in the server room and I've only pressed it a couple times.
    – Ben Brocka
    Commented Jun 25, 2012 at 21:28
  • All of our buttons have different icons, but apparently that wasn't visually distinctive enough. What do you think of just changing the font to red? We will add more styling to the alert box, also.
    – Maltiriel
    Commented Jun 25, 2012 at 21:56
  • 1
    If it's "permanently delete" then the wording on the popup should be accordingly, using "may not be undone" gives impression that it "may be undone" also..
    – Ades
    Commented Jun 26, 2012 at 3:46
  • @Maltiriel: I thought that greying out the Launch Nuclear Missile At Nasal Cavity™-button would be the more obvious option, rather than making it red. Keeping strongly in mind of course, that greyed out buttons strongly convey the message "This function not available atm."
    – Jonta
    Commented Aug 16, 2012 at 18:31

Rather than simply "This will delete your data. Are you sure? [Yes][No]", have a positive action:


download bmml source – Wireframes created with Balsamiq Mockups

Only checking the checkbox and clicking OK will do the action. Any other combination will not.

As an aside following comments: the OK button should probably be more explicit, like Delete, but there is not enough data in the question to suggest what it should be (which is why my dialog is rather vague about the unrecoverable action).

It's reasonable for the OK button to be disabled and for the additional action to enable it.

  • 3
    I was just about to post this. I've done this a bunch of times. When combined with the additonal styling and colors mentioned by @MattLavoie in his answer, and disabling the OK button until the checkbox is checked, it works really well.
    – GotDibbs
    Commented Jun 25, 2012 at 20:52
  • 1
    Yeah I suppose actually typing "Do the horrible thing" before you can continue might be a bit overkill, but I have totally pulled that one before didn't really feel bad about it. Commented Jun 25, 2012 at 20:54
  • From personal experience (user-side), I think typing reinforces the commitment much better than a checkbox. Especially, when it's typing something random like a string of numbers (Western Digital's RAID formatting utility).
    – dnbrv
    Commented Jun 25, 2012 at 21:21
  • 2
    I don't like that your buttons are still okay/cancel. Ideally the button should at least say Delete. Interesting way to try and force the user to read the whole dialog though
    – Ben Brocka
    Commented Jun 25, 2012 at 21:27
  • 3
    “OK” as a synonym for “launch the nukes” sounds too innocuous. People often don’t read the text, just the buttons. Commented Jun 26, 2012 at 10:23

What asking for is a better forcing function. As defined by the Interaction Design Encyclopedia:

A forcing function is an aspect of a design that prevents the user from taking an action without consciously considering information relevant to that action. It forces conscious attention upon something ("bringing to conciousness") and thus deliberately disrupts the efficient or automatised performance of a task.

From what you described above, your first forcing function, the alert box does not seem to stop users from still click the yes button. Another type of forcing function I have discovered that might help is to use a modal dialog and ask the user to enter a value into a text box. The value could be the file name or even something simple like "delete". This prevents your more click happy users from simply asking them to select either yes or no. Demo below:


download bmml source – Wireframes created with Balsamiq Mockups

Depending on your results here you can refine this more by only accepting upper case values and so on.

  • 3
    +1 for zooming out to mention the forcing function pattern. There's a variety of ways of implementing this which should all be fine as long as they follow general forcing function guidance. Google Book search shows some good excerpts about forcing functions from Design of Everyday Things - Don Norman Commented Jun 26, 2012 at 1:10
  • 3
    Github has a similar forcing function to your mockup for deleting repositories. Commented Jun 26, 2012 at 1:17
  • 3
    This is really the only acceptable alternative and should be used much more. However, I would definitely make the prompt more specific where possible – e.g. the file name to delete, as you mentioned. This prevents the user from just typing “DELETE” on auto-pilot without checking that they did delete the right file etc. Commented Jun 26, 2012 at 10:21
  • This reminds me of old command line games.
    – Jay
    Commented Jun 26, 2012 at 10:32
  • @KonradRudolph Good point! For mockup purposes of this I left the text pretty generic, But you are correct it should at least present the user with a title of what they are about to delete.
    – JeffH
    Commented Jun 26, 2012 at 11:03

While, not the prettiest by far it was memorable enough and a bit humorous.

While rooting my tablet I was going to do an unrecoverable action and here is the screen I had viewed (I had to manually hit down to scroll through each option):

'Are you sure you wish to complete this unrecoverable action?'






-Yes, I wish to perform this possibly fatal action




What I miss in the answers already there (though some do it implicitly), is a quite basic principle on dialog boxes: make the actual action clear on the button itself! Reading only the button should already indicate what is going happen. "Yes" and "No" don't mean anything if you don't read the rest of the dialog. Did you ever see the horrible "Click Yes to Delete, No to Move or Cancel to Archive" type of messages?

So, instead of asking a yes-or-no question, ask the question in a form so that the actions on the buttons ("Delete", "Move", "Archive") are understandable on their own.


In this case I would:

  • clearly separate the delete and cancel actions (one a link, one a button)
  • use the path to completion as a blocker (place the cancel link where you're most likely to read/click)
  • reduce text (they aren't reading it)
  • make the button look destructive.


download bmml source – Wireframes created with Balsamiq Mockups

Replace "delete" with your action name.

  • 7
    I would not make the Cancel option (the save, default option!) be so much less obvious than the dangerous Delete action. That would give users the feeling that Delete is really the only thing they could do.
    – André
    Commented Jun 26, 2012 at 8:22
  • 1
    @André I agree, I would swap the two options around (position and styling) so the Delete is the less predominant option.
    – JonW
    Commented Jun 26, 2012 at 12:40

Clearly the users are not reading or interacting with your existing dialog. Therefore putting more words/dialogs/actions to be completed will not help - they will simply perform them as routinely as the other actions they are performing.

The best suggestion I have seen is from @Dani, of delaying the action a short while, and allowing them to undo it in this time-frame. It depends on when your users realise they have made a mistake.

Other alternatives are to restrict who can perform this operation, and make sure they actually do it only when they should (tricky), or require approval of the operation by someone else before it is activated - akin to the delay actioning, but with more direct control.

Another approach taken by some organisations I have know is to provide the undo facilities by a DB update, but make the cost of this (either in system downtime or money) significant, which means that doing this action in error becomes expensive. People do then learn.


One pattern I have seen is to have the button change text and size after the button is clicked once . Only the second click performs the action.

[Delete] --> [Confirm deletion]

Maybe some more text explaining the action that show up.

  • Interesting idea. However, which way should the resizing happen - should the button get larger or smaller once it's been clicked once?
    – JonW
    Commented Jun 26, 2012 at 11:32
  • My thought was that it should grow to contain the longer text, but any resize should serve as a notification to the user. Commented Jun 26, 2012 at 11:46
  • I've used a similar pattern, where the [Delete] buttons becomes a [Cancel] button, and a new [Confirm] -button appears next to the delete button. The idea is that you should not be able to confirm by double-clicking. You'll have to move the mouse a some pixels. Still you don't need to move it all the way to the centered confirmation box many people uses.
    – Vegar
    Commented Jan 17, 2018 at 9:56

Get it to produce a second modal alert.

"Are you really sure you want to permantly delete data ? Y/N"

And then if testing shows they're still not getting the message, a third one:

This will delete it forever you know.

Are you quite sure you want to do this ? Y/N

( Part of the approach being to shift from formal business English to something a bit more 'chatty' so that they finally take note of what's going on on screen )

  • 2
    I'd be afraid this would just make people even more apt to click to make it go away. Have you used this approach with success?
    – Maltiriel
    Commented Jun 25, 2012 at 21:57
  • I agree I think this sends users into click anything mode... Commented Jun 27, 2012 at 8:00
  • Sounds like a suboptimal solution, but if you do this, maybe reverse the question at least once, so that repeated clicking doesn't work.
    – Ian
    Commented Jul 1, 2012 at 23:49

Another approach presented at CHI 2016 was to force users to wait for 10-20 seconds before letting them confirm the action.

The analogy given by the author was: if you're cutting a tree branch with a hand saw, you're more likely to realize that you are sitting on that same branch than if you were cutting it with a chain saw.

Compared to the "type delete below" method, this one has the advantage of giving you exactly nothing to do for 10 seconds, which forces users to think about the action they were going to perform.

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.