Where should a delete action be inside a menu?

Question

I work on a product that has various menus throughout the application.

Recently a customer complained that they had accidentally deleted an object from the system, rather than edited.

They have requested that we move the delete action, but I am unsure where it would best fit.

We already have confirmation dialogs to which they said they wasn't concentrating and just clicked "Yes". I have read that perhaps you could prompt for password or some form of captcha to prevent accidental deletion, but I am a little miffed to do this slowing down genuine site usage to prevent stupidity.

I guess I am really looking for ways to prevent accidental clicking, rather than modifying the dialog.

My first thought was to always move the delete action as the last item in the list, with a separator above, but then started to think that perhaps a Microsoft approach with quick actions above would be better? I could align the trashcan to the right, separating it from the other items.

Any other suggestions / insights would be welcomed.

Answer 1

As a user, I would fall into the group of those who make a mistake and delete the item, but not only because of the location but also because of the lack of perceptual contrast between "Modify" and "Delete."

Mainly I would opt for the position change, as mentioned in the question, and at the end of the list of menu options.

But on the other hand, I would incorporate a greater perceptual contrast between each component. Modify and Delete, despite having different icons and texts, due to the icon size and length of the word, they show little contrast, which means they can be easily confused in a work process:

I would look for a way to exaggerate the perceptual differentiation between the two:

In the image below, the YouTube Studio items menu, where I don't think the difference in length of each text is a coincidence:

Answer 2

To reduce user errors, I would put the delete action at the end of the action list. Also, add a red colour to the irreversible action.

Answer 3

I'd say, make those options a little more difficult to reach and use: place them separately, use separators, maybe use confirmation dialogs, if it won't damage the flow. (I think CAPTCHA and password should probably not be used on mundane use cases, simple confirmation dialog could be enough to catch possible misclicks.)

There's this great article by Nielsen Norman Group: Dangerous UX: Consequential Options Close to Benign Options that goes into it in detail.

Essentially,

Preventing errors is better than helping users recover from them.

Two options that are related (like Save and Delete) could have very different effects. Therefore, designers must strive to differentiate between such options as much as possible. The label is one way to individualize them, but it’s not enough. And, of course, when we design digital products like websites and applications, we cannot use tactile properties. But we can rely on visual treatment and on positioning.

Grammarly, for example, uses the same position of spell correction and Add to dictionary options as Firefox does, but critically, uses several other cues such as color, icons, relative size of text, and alignment to prevent user slips.

Another option is to separate the consequential option (e.g., Delete, Discard Changes, Mute, Make Default) from the others by placing it farther away from them. It’s okay to leverage Fitts’ Law and make it a little harder to select the consequential option, especially if it’s going to be destructive. The few additional milliseconds that it might take a user to move their mouse or finger to the other option is nothing compared to the frustration and time it would take to undo a major error.

Avoid placing highly consequential actions (that will require a lot of user work to fix if accidentally triggered) directly next to options that are benign. Add additional space and redundant visual signals to indicate which options are different than other, conceptually related commands.

Answer 4

If the primary button is labeled "Yes", then you could change it to something like "Delete '...'", which indicates an action that performs the next task. The color of the button is red which distinguishes it from another primary color.

Answer 5

I agree with the comment that an Undo capability would be a good addition.

The Delete menu item could have a sub-menu with Confirm delete. This would avoid the problems associated with the "always click Yes or Ok" mental orientation.

Answer 6

As a follow up on exp's answer, perhaps you could group actions by dangerousness. For example, all undoable actions in one menu, all irreversible actions in a separate menu. This one full of "danger! danger!" cues. Perhaps the criterion is "the level of thoughtfulness required": trivial, pause, really-think-it-through.

Answer 7

Confirmation dialogs often get ignored because they are getting in the way of people's flow. You can help reduce this by using as little text as possible in the dialog (so the user can read it quickly), and including the most important information on the buttons themselves.

Rather than:

Are you sure that you want perform this action? 

[ OK ] [ Cancel ]

Consider:

Permanently delete foo?

[ Delete ] [ Keep ]

You can even consider changing the default button to the non-destructive action - Keep.

Answer 8

We already have confirmation dialogs to which they said they wasn't concentrating and just clicked "Yes"

A button in the deletion confirmation dialog should better be labelled "Delete", not "Yes"/"OK", and it shouldn't be the default one which is pressed when the user hits Enter or Space.

I have read that perhaps you could prompt for password or some form of captcha to prevent accidental deletion, but I am a little miffed to do this slowing down genuine site usage to prevent stupidity.

Rightfully so. The time lost by 1% of users who lost 10 minutes of their day's work because of a deletion is an equivalent of 6 seconds per user. The time lost to solve CAPTCHA will impact 100% of your users, and I'm pretty sure it will exceed 6 seconds per day.

If deleting is relatively rare and has no side effects beside the obvious ones (such as the possibility to reuse the deleted object's name), you could actually make deletion reversible by keeping deleted objects around for a certain time.

Where should a delete action be inside a menu?

There is no general rule. If your items have "Cut"/"Copy"/"Paste"/"Rename" actions defined, it makes sense to put "Delete" at the end of this block. In the example you provided it looks OK right after "Modify". Don't overthink this.

Answer 9

Some good options that I've used in the past are:

1. Space out the Delete Option away from other elements if possible (Using a spacer bar is a good choice for this)
2. Color the option red. If you have a trash icon beside the option, you can just color this red without coloring the whole button. The idea here is to ensure that the option isn't easily mistaked for another option.
3. Confirmation should be obvious and distinct. The delete option again should be obvious but not the easiest button to Click eg. Have the Delete option colored red but have a Cancel option that is an actual button while leaving Delete as just text.
4. Manual Confirmation can additionally be used. Disable the Delete button and make the user complete a task such as having to type delete project-x to enable the Delete button. This removes any confusion to the user that this action is deleting. Additional provisions must be used though for mass-deletion events if your project requires. You can have a check-box to disable Manual Confirmation for a period of time via Cookies or additional methods for Mass Deletion such as having a checkbox available to select multiple items before selecting delete.
5. Undo option if available for data. This might not be possible for every system, but designing a delete that simply marks the item for deletion which would actually be deleted after N minutes/hours/days by another automated system. This allows users to soft-delete and be able to come back within the time period to reinstate the item.