Improving destructive action confirmation in iOS7

The confirmation dialog framework for iOS7 is poorly designed. The best example of what can go wrong using it is the dialog presented to a user when they cancel drafting an email:


In UX design, there are a few things that are so bad I would classify them “sins of design”. I’m certainly not the first to use that phrase, although opinions on what makes the list varies. Topping the list for many, however, is irreversible, destructive actions which do not require confirmation.

The more destructive and permanent an action, the more a UI needs to guard against that action being taken by accident. The ultimate guard against these actions is ‘undo’, but that is not always available. So when actions are destructive (like deleting a file) or irrecoverably destructive (like canceling a mail draft without saving on iOS), applications that want to keep their users happy present confirmation dialogs.

A brief digression: greater scholars of UX than I have written quite a bit about the need for undo everywhere, so I’ll not rehash those arguments here. I will say that the reason it is not universal is that offering a user undo for every possible action can be challenging to implement, either because of computational requirements (like keeping multiple revisions of giant bitmaps around forever) or due to the need to make difficult decisions about what is correct behavior (does a user need to undo moving a tool palette?). It can also be tedious.

The guidelines for designing these confirmation dialogs are well established. They should be very clear about which option is the destructive one, and they should make the user perform an interface adjustment action to select the destructive option, thus forcing a cognitive evaluation.

What I mean by an interface adjustment is that it should not be possible for a user who accidentally doubles the action that initiated the destruction to confirm the destruction. Thus, the “confirm delete” button should not conveniently appear exactly where the initial “delete” button was, because if the user accidentally re-clicks, they confirm without getting a chance to re-evaluate, defeating the purpose of the confirmation dialog in the first place. Likewise, the destructive action should never every be the default choice.

In practice, it’s pretty easy to make sure the user can’t accidentally click the confirm button, but applications frequently neglect to make the outcomes of the choices obvious, and occasionally allow the destructive choice to be the default.

Here’s an example of a well designed destructive confirmation dialog:

OS X Mail Draft Delete Dialog

This is the message OS X Mail gives you if you attempt to close a draft message before saving it. As we can see, the two “safe” choices are on the right, grouped together. “Cancel” is safe because it cancels the close action and leaves everything the way it was. “Save” is safe because the draft is saved. The sensible default is “Save”, because we assume that most of the time the user initiated the window close on purpose, and it is not destructive. The destructive choice, “Don’t Save”, is separated from the other two and cannot be activated by either of the standard dialog hot keys (Enter for confirm and Esc for abort).

So what about iOS7’s confirmation dialogs? Look again at the above image for canceling a draft in iOS7 Mail.
At first you’d think the destructive action is pretty well indicated with the red text, but in UI design you learn that color alone is insufficient as a cue, as many people are color-blind. In fact, in terms of grouping the options, this dialog is improper — the destructive option is grouped with one of the safe options, and the other save option is separate. In terms of ease the user is always forced to move their finger from where it was (tapping the “Cancel” word in the upper left).

This is how this dialog should look:

Improved iOS7 Mail Draft Delete Dialog

As you can see, the two safe options are grouped together, close to where the user’s finger is already. The “Delete Draft” option is safely separated at the bottom of the screen, at the opposite point from where the users’s finger is, and the default (in a touch interface, default means where your finger is already) is “Save”.

Leave a Reply