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.

Example of menu used in application

Maybe like Microsoft?

  • 20
    Does your system support "undo" for this action? One good undo feature can cover for a lot of other UI surprises. If the "delete" action is something very rare that's too big to feasibly undo, then I agree with putting a scarier dialog that makes them confirm with a password or similar. Commented Sep 6, 2023 at 18:09
  • 2
    How common / important is deletion within your context? A pattern I like is that for dangerous actions (e.g. deletion) you need to type the name of the object you intend to delete as a level of confirmation - i.e. you get a popup - "You have tried to delete the object 'My Object'. Please type 'My Object' in the text-box below to confirm' Commented Sep 6, 2023 at 22:29
  • 3
    If deletion is not something that's common (e.g., deleting projects), then adding the requirement to type something doesn't really slowing down genuine usage. If it's a common action, then that's something else.
    – justhalf
    Commented Sep 7, 2023 at 4:40
  • An easier "quick action" for delete sounds like it might exacerbate the problem
    – JamesFaix
    Commented Sep 7, 2023 at 16:48

9 Answers 9


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:

enter image description here

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

delete the item

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

Youtube Studio

  • 9
    I guess changing "Modify" to "Edit" might also help here. Commented Sep 6, 2023 at 22:26
  • 1
    Apologies, the screenshot I have here is doctored to remove the element that is being modified / deleted as we use the pattern throughout the application. "Modify Pattern", "Delete Pattern", "Modify User", "Delete User" etc. Its an interesting idea to remove the "What" element from the "Modify" link though. That would certainly help at a quick glance as shown in the blurred images above.
    – Matt S.
    Commented Sep 8, 2023 at 14:41

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.

  • 2
    I have never really tried applying colour to the menu items themselves, I will have a try see how it looks.
    – Matt S.
    Commented Sep 6, 2023 at 13:28
  • 1
    @MattS. I have seen this pattern of applying a red background color to the delete option (which if I recall correctly also puts the delete option at the end of the list as suggested here). Unfortunately I don't remember what specific application uses this pattern. If you go with this pattern, perhaps you should make it a sufficiently dark red color and make the text white so that color blind people can pick up on the contrast. Commented Sep 7, 2023 at 15:58
  • Slack does that. Right click on a message sent by you will have a delete with a red text that is also highlighted with a red background.
    – bracco23
    Commented Sep 8, 2023 at 9:49
  • GitHub also does that in actions such as deleting a repository or changing its ownership. Or Discord when deleting a server as well, for example. Commented Sep 9, 2023 at 13:48

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.


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.

  • I quite disagree. Making a consequential action "a little harder to select" is not going to prevent the error, it will only make it occur more seldom... but that just gives Murphy's law more of a chance that the one time it does happen is the one where it hurts most, and then the user will be extra helpless because they haven't experienced this before. Instead, all actions that actually crop up in regular work should be easy to reach and easily undoable, and only the true "nuke" options should be hard to reach (not just harder to click but hidden in a deep menu and with extra confirmation). Commented Sep 8, 2023 at 11:58
  • "that will require a lot of user work to fix if accidentally triggered" there is no undo. So its a bit more than a lot of work! I am starting to think that actually this may be the bigger issue and UI changes won't necessarily fix that.
    – Matt S.
    Commented Sep 8, 2023 at 14:46

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.

  • 9
    Unfortunately the button colours are fairly uniform throughout the application. We already use Red for delete, and it does say "Yes, Delete" + "No, Cancel" honestly I am pretty sure the customer is just trying to get out of jail for doing something stupid, but its been landed on my plate
    – Matt S.
    Commented Sep 6, 2023 at 13:29

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.

  • The submenu-to-confirm is a nice idea! Never seen it before! Would need some testing, right?
    – Pablo H
    Commented Sep 7, 2023 at 13:28
  • @PabloH, there does not exist anything that does not need testing. :-)
    – lit
    Commented Sep 7, 2023 at 13:51

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.


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 ]


Permanently delete foo?

[ Delete ] [ Keep ]

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


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.

  • 1
    Apologies, the confirmation does use "No, Cancel" and "Yes, Delete". I didn't make that clear. My general thought was not to give it too much thought, it has been like this for around four years now, but customers are always right for some reason!
    – Matt S.
    Commented Sep 8, 2023 at 14:44
  • 1
    @MattS. Actually, no, customers are not always right, and some are even worth losing. I'm not saying this one request is decisive, but if this customer repeatedly won't learn how to use your software and instead asks you to implement features that work around their lack of expertise or attention, I would definitely refuse to work on such features unless they agree to cover the costs. Commented Sep 11, 2023 at 7:33
  • 1
    I can assure you I said that whilst my eyes rolled entirely into the back of my head!
    – Matt S.
    Commented Sep 11, 2023 at 14:25

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.
  • 1
    The space and color will be the easiest options for sure. An interesting idea with the cookies being used to disable the "slower" method of deletion. I like it!
    – Matt S.
    Commented Sep 11, 2023 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.