Drawing users' attention to unrecoverable actions?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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?'

-No

-No

-No

-No

-No

-Yes, I wish to perform this possibly fatal action

-No

-No

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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 )

Answer 10

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.