Should a delete action's "undo" be underneath the "delete"?

Question

Take for example this button:

                 _________
                /         \
               |   Trash   |
                \_________/

Which when clicked, becomes this:

   _________     _________
  /         \   /         \
 |  Restore  | |  Destroy  |
  \_________/   \_________/

Which means that when clicking on the delete button, your mouse is already on the confirm button, which allows a quick double click to delete. This is good for deleting many items quickly. But a naive user might accidentally double click on the button, resulting in a permanent delete rather than a prompt to confirm.

The action I'm implementing is a Trash / Restore / Destroy pattern, where you have the option to either restore or destory an item that has been trashed.

What's better - protecting the user from an accidental destroy or allow faster deletes by having the confirm to destory action "underneath" the trash button?

Answer 1

This is one of the most common design patterns.

A lot of research has gone into delete confirmations, so it's impossible to cover all the variants in one answer: the best solution for you will depend on the degree of confirmation, warning, speed, and likely user intent.

That said, here's one approach which represents the 'state of the art' in delete confirmations:

• For most applications, the majority of users who click on Delete actually want to delete an item. For example, let's say >85% of delete clicks for your app are well-intended and <15% are unintentional for various reasons (accidental click, user changed mind, user didn't understand the button, etc.)
• Therefore, for >85% of cases, an extra confirmation or click is an unnecessary impediment for users.
• Therefore, the best solution that works for the vast majority of cases is just a Delete button with no added confirmation step.
• Now, we still have to deal with the <15% of users who delete unintentionally. Since this is a minority case, an Undo button that allows users to fully unwind the deletion works best.
• Here, the Undo button should not be placed near the Delete button, to avoid accidental undos. It should be clearly placed somewhere close by so that the unintentional user can rewind the transaction.
• The Undo button should be visible for long enough for the user to reasonable reconsider an unintentional delete, but not so long that it sticks around intrusively after the user has gone on to do other tasks.

This is just one of many approaches, but I like it because it incorporates a proper prioritization of usage, and creates cognitive flow and friction at the right time. Your needs may be different so you may require a different approach with more/less confirmation and more/less eager deletion.

The 'no-confirmation' approach is used in apps like Gmail, which provide a single button for delete, and then use a visible snackbar or toast that appears for a period of time after the deletion to allow the user to undo the delete.

Since back-end implementation is not part of the UX design, I'll add a comment below with a note on that.

Answer 2

I had a similar challenge to implement a switch, which has same functionality as a "Are you sure?" dialog. We implemented a switch, which slided its surface to the left to uncover the real action button ("Destroy" in your case). One very important thing we found out is, to slide the cover so that it is still bigger than the half of the whole button. So most accident double clicks (on the left and in the middle of the button) will be catched and Undo/Disarm is clicked. Another thing was the animation. It was essential to show via animation, that the "Delete" cover flows/shrinks on top of the uncovered "Ok?" button, to visualise the hierarchy/sequence of the action.

Following mock shows the flow. I hope this gives you some useful input.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 3

Let's pretend the below scenario

It's well known that how frustrating it is when you delete something you didn’t mean to final deletion. Whatever you delete which usually is gone forever. It’s very important to have confirmation windows when a user clicks destroy (You implemented here restore and destroy buttons after clicking on delete). However, the confirmation buttons could still lead many users accidentally click destroy button instead of clicking on restore. Sometimes users don’t read the confirmation dialog/buttons and just push the destroy button because it’s easier. Sometimes, users think they can undo their destroy. In other cases they actually read the dialog, but accidentally click the destroy button where actually they meant to click on restore.

The Solution

Whatever the case is, users usually make mistakes on confirmation and our role as an UX is to guide the users to the right direction. Rather than giving the users confirmation message with restore and destroy buttons that they could mistakenly press, give them a text field and ask them to type the word “destroy” to final confirmation where they totally should be aware of that.

Answer 4

Any button under a button is going to lead to unintentional clicks
An unintentional destroy is not a good thing

If you want fast Destroy then why not just let them shift + Trash to Destroy it?
That is how it is done in Window File Manager.

Answer 5

The way I'd recommend handling this would be hugely different depending on the nature of the application. Ask yourself the key questions:

• How often are users going to be deleting an entry in typical use?
• How much will be lost by an unwanted delete?

If you're designing an application where deletes are rare, such as when they are only be used in the case of correcting a user's error, then it is usually a better choice to make deletes more difficult. Little will be lost by making the user do a lot of work.

If you're anticipating frequent use of the deletion process, however, making the user do more work becomes a major issue. Examples would be a mailbox or a queue or task list where the user deletes items as they get processed or completed.

Also consider the cost of information deleted in error. In the case of an email or messaging inbox, a deleted message may contain irreplaceable information. On the other hand, if the deletions are just from a user-generated list of short items (such as the list of species on an eBird observatiion, or the list of tags on a blog post, etc.) then the cost of deletion is low.

Except in the "low stakes" scenario I described last, I think it is best to avoid the possibility of accidental permanent deletion through double action. This includes double clicks (don't make the "destroy" or "confirm delete "button appear under the "trash" or "delete" button when clicked) and also keypresses (A problems on webpages and some database forms is when people are navigating a form by tabs, press "enter" to delete a record, and then a javascript dialogue or other box pops up where "OK" or "Confirm" is highlighted by default and pressing "enter" again selects it.)

If the stakes of deletion are high, these are best avoided.

tohster's solution with an "undo" button is accepted best practice in some situations, but it is sometimes a lot more work to implement an "undo" button.

I personally only recommened implementing an "undo" button in the scenario where typical use involves frequent deletion AND stakes of deleting in error are high. An example would be a mail program, and this is probably why programs like gmail use this approach.

For something where deletions are rare, a cumbersome confirmation process is not a big imposition on the user.

And for something where accidental deletions have low stakes, you may not even need to confirm, and if you do, it's not a big deal if you allow double clicks or keypresses.