Verifying that a user acknowledges and understands a given message without adding excess inconvenience

Question

Say the user wishes to perform a dangerous but necessary task, from which there is no recovery or going back (for example, erasing a hard drive, or permanently deleting an online account after confirming they don't want to simply disable it - these are just examples, it could be something done more frequently).

There is of course always the issue that the user has not entirely understood the implications of the actions they are about to take (or even understand the action itself) - so of course it is necessary to prompt the user to confirm their choice of actions.

Bearing in mind the seriousness of the task they might be about to do, how can you get a user to confirm their choice of action and acknowledge that they understand the consequences in such a way that:

A) They aren't inclined to ignore warnings or messages explaining what's about to happen and just jump straight to whatever button/tickbox will move to the next step.

B) The user experience isn't degraded by excessive prompts, warnings and hurdles that may bore the user and increase the problem outlined in A.

C) Allows you (the service provider/developer) to have some indication that they really did see any warnings you gave them so they can't turn around afterwards saying they didn't see a warning when they actually just ignored it.

C would seem the tricky one. My first inclination would be to require the user to answer a question about the task.

So in the case of erasing the drive, you might ask them "What will happen to any personal documents stored on the computer? A) Nothing, B) Permanently destroyed, C) Automatically backed-up" - and if the user answers anything other than B, don't allow them to continue. While this may work in that particular context, I can't think quite how you'd adapt this to other situations, and it does seem to beckon point B again where you're interrupting the user.

Answer 1

I would recommend clearly going with an approach which clearly calls out the the potential impact of the action they are going to provide and require them to provide a second level of confirmation. The second level of confirmation can be perhaps done by using a checkbox (like how you have in terms and condition boxes) and then only enabling the delete or affirmative button or even requiring the user to enter a specific text to confirm the action.

You also need to look at the design of the confirmation popup to ensure it stands out and is not dismissed by the user as one of the many popups which the system might show accepting whom which have no real impact on the system. A excellent example can be gleaned from this article The UX of Confirmation Modals.To quote the article

In the app I design, there used to be a way to delete many of the important objects in the database. This was an important feature, but also a dangerous one for obvious reasons. Saying “This will delete these leads, are you sure?” was no working. People ignore these sorts of messages. I needed to get them to think more clearly about the problem. This is what I came up with:

Several “features” of this modal.

• Imagery. On the one hand, it wakes people up. ”Ooh, this looks serious!” On the other hand it is partially whimsical. ”Ooh, that’s cute!” It simultaneously pokes the user in the brain in two different ways.
• Language. I say, “Delete, Destroy, No Going Back, Can Not Undo, Erase”. I tried to use every conceivable language that will get the user to think, “Hmm, will this really delete these leads?”
• Makes them think to complete the task. The bottom right button is disabled until they put in the correct number of leads that will be destroyed. Additionally, they need to check the box. You can’t just click YES. You need to think to come up with the correct number.

This modal was an unqualified success. The problem (“I accidentally deleted my leads”) has never happened since the modal was put in place. Additionally, several comments on it’s effectiveness have been received. I love this modal because it accomplishes its goals without being mean to the customer.

I also recommend reading this article How To Prevent And Minimize Errors: Part III for additional inputs on best practices for creating confirmation messages

Answer 2

I think the most important thing is to not use standard controls, and instead make it a distinct experience that's directly tied on the task at hand.

Say the user wants to delete a drive. So force them to actually do an interaction that emulates deleting a drive. As a random top-of-my-head example, have them drag an icon representing their files into a big animating fire graphic, then give them ten seconds to watch the papers burn so they can change their mind if they want to.

Always remember that the default answer to every dialog box is "Cancel".

Answer 3

The last sentences sounds like when I was in the navy and had to do my gun exam. You got a form with 10 questions, and you kept on writing the form until you got all answers correct. That correct form was filed and could be used in the event that I did something wrong since I "knew" what I was doing - referencing the 10 of 10 correct answers.

But apart from that, all you really can do is help the users along the way at the same time you save your business. Keep records of that users clicked a certain button with a certain legal info. Avoid click-through dialoges, since some users are too familiar with all the dialoges popping up "Are you sure?"; "Are you really sure?"; "Really really?"...

The best way is to inform your users in an unfamiliar situation. Use non-standard colors, different sizes and really big fonts just to get users attention. I belive that's the only way you gan "wake" users and when you have their attention - you could use the control question.

---

Also you have a reference question here already in the question Which button should get the focus at delete dialogs?

Answer 4

I like the post above with the dynamite image (+1) when it comes to creating a really strong message.

If your needs for a warning don't point at a message so strong one of the simplest method is to have two different types of prompt screens - one for the usual prompt "sure, do it and get out of my way" confirmations and another where you really want them to read and understand the warning.

The "prompt" view should be used mostly everywhere and "warning" view should be used sparsely. They should have different layout - don't put the OK/Cancel buttons in the same spot or you'll get automatic responses from users. For example if "prompt" view has standard OK/Cancel horizontally stacked in the bottom right corner then put the equivalent buttons in the "warning" view vertically stacked on the right side.

It's also important to shorten the warning message or it will be ignored. You can add other perks, such as a checkbox, answer box or password box that require user input before the "proceed" button is enabled.

Images and colors are also important, such as the image posted in another answer.

Humans instinctively want to optimize every task that occurs repeatedly, so what you want here is to prevent them from recognizing the "prompt" and "warning" tasks as identical and therefore relying on their habitual response.

Answer 5

Usually doing critical actions in a system requires more rights. So one user can do it but another one can't do. In case action is protected by administrative rights it has almost usual interface without any technologies - maybe only one more confirmation step. Why? Because we suppose that a person understands his responsibility. He may not know real effect of action but he realizes his responsibility.

So another solution is to disable critical actions by default and make separate setting/menu/command/whatever which is named 'For advanced user only!' By changing this setting and making available critical actions after seeing big warning message user agreed that he is responsible for results. Also he could be advised to invite somebody else who knows possible results.

Answer 6

This is an attempt to protect the user from themselves, and as such it is subject to the fallacy of attempting to create an "idiot-proof system"; idiots are just too resourceful to make any such endeavor 100% effective.

Given the above, and the fact that these types of "dangerous" actions don't occur every day, I would say that forcing the user to re-authenticate, coupled with an extra "I confirm this action" checkbox (which obviously wouldn't be present on a "normal" login screen), would serve several useful purposes in this scenario:

• You force the user to prove that they're still who they were when they logged in. This is instrumental in avoiding "AFK hacking", where someone leaves their terminal logged in and someone else uses that logged-in terminal to do damage.
• The user's authentication and confirmation can be logged; since it has to be vetted by whatever authentication system is being used, it's usually trivial to include the context in which the user is re-authenticating and log it along with the user, date and time. That avoids "non-repudiation"; you know that the user's correct username and password were entered into the system, from an IP/MAC address you can easily confirm belonged to the user's own workstation at the time, for the express purpose of performing this dangerous task. That requires a conscious action that the user cannot reasonably claim they did not do.
• You force the user to think very hard about what they're doing: "Ooh, this feature requires me to authenticate again. It must be some heavy stuff".

This does of course assume that your software requires the user to authenticate in order to do anything with this system, much less anything dangerous. Hopefully that is a safe assumption to make.