Should "dangerous" buttons be big and red or small and inconspicuous?

Question

In a web app, some people think a "Delete" button should be obvious and bright red, signifying danger. The trouble is that this draws the eye to the button and may make accidental clicks more likely. So in general...

Should "dangerous" buttons be prominent? Or should they be inconspicuous?

"Dangerous" buttons are buttons that users should never click by accident. Typically these are secondary action buttons that cause destructive actions, regardless of whether they require confirmation or are undoable.

I wonder if this issue has been dealt with elsewhere. I notice that the icon on Microsoft Outlook 2007's Delete button is just plain black, whereas IIRC it used to be red a few years ago. The WordPress blog editing page goes even further: the Save button is big and easy to click, while the Delete button is a small plain hyperlink that does not attract the eye. There are many other examples.

I've seen this "inconspicuous destructive button" pattern used in lots of places, but haven't seen a decent reference to it. Is this issue discussed in any books or websites?

Answer 1

There is a small snippit of information I can add. Bruce Tognazzini posted on AskTog some years ago:

" It would appear at first glance that painting the close box red is a good thing, since that warns the user about its potential danger. However, a study done at Apple almost ten years ago found that the user's mouse gravitates toward red objects almost as though they were possessed with magnetism. The study forced us to abandon the idea of making close boxes and the Shut Down option red. “

It may add some sway to your decision, but I can’t say that I’ve been mindlessly clicking close for the past 9 years in Mac OS X!

Answer 2

Depends.

For example, if your users are likely to use keyboard navigation (ie business applications) and the focus is automatically on the delete button, then the size isn't really going to matter if they expect hitting Enter is going to do something else.

Just as an example for why it depends.

Is delete a likely function within the context of the screen and tasks? Is a delete reversible?

Other things to consider is distance of the button from the target area - ie if you have to check a box on the left side of the screen and then move across to the far right to click delete then that matters; also the proximity of the delete to other options.

Things like icons (the red X or the garbage bin) can either reduce the target acquisition and recognition time ... or hinder it, if implemented incorrectly.

So, sorry - there's no right answer to this question.

Personally, I don't like Wordpress' new implementation - it makes the delete feature too hard to locate.

If people are accidentally clicking the delete button and it's not an oft used function then consider a two-step delete+confirm or select+delete implementation, or move the button, or add/remove iconography, make it bigger, more whitespace around it etc.

Answer 3

Sometimes the delete button IS the primary action, then it should be more prominent, otherwise it should probably not stand out that much. I too like the way Wordpress implemented it with an insignificant plain link that gets a very noticeable red background when hovered.

I tend to think that what happens after you click the button is more important than how it looks. If the action is reversible (undo function) then it's not so dangerous, and the cost of accidently clicking it is very low.

I prefer to have an undo function to the delete action but if that's not possible then there should probably be some kind of confirmation. Lately I've been borrowing a design pattern from the iPhone in my Web apps. And that is when you click the delete button, it changes into a new button with the label "Confirm delete" or something similar. The delete action isn't performed until the "Confirm" button is pressed. I think that this is a more unobtrusive way of asking for confirmation than the oh so common Alert box which should be avoided at any cost:-)

Answer 4

I think it very much depends on the context of the button, and even on it's context within the overall application. There may be parts of your app where "Delete" is less "destructive" than in other parts. In that case, you have a consistency issue to address. Also, as rightly pointed out, sometimes delete is the primary action on a list or on a screen. So you have to balance what primary actions look like throughout the rest of your product with the functionality of the delete itself.

As a secondary consideration, what do users expect when it comes to delete buttons? The 'X' is fairly synonymous with delete functionality and the colour of the 'X' (you mentioned Outlook) doesn't seem to be too crucial. I believe users appreciate (if not necessarily expect) to be prompted to confirm a deletion - although that again goes back to the question of just how destructive a deletion might be and whether it's easily undo-able.

Whilst I believe that how things look is now as important as how things work (in an overall sense), I feel that this sort of thing is governed more by the operation as opposed to the aesthetic.

Answer 5

If "Delete" is dangerous, make you sure you ask the user "Are you Sure?"

I think all of the above comments / answers are good and relevant. Can I offer a second-layered answer to this question? In the end, I think one of the most important aspects of protecting users from wreaking havoc by accidentally clicking "Delete", is to provide a more fail-safe layer to the option:

By this, I mean, make sure you say "Hey! Are you sure you want to do this?"

Answer 6

...Neither...

Your choice of changing the presentation of a functionality should not be based on the outcome of the action but on the actual use the user has for it.
If an action has a behavior that can be detrimental to the work-flow if selected by error then change said behavior to reduce the impact on workflow.
This way you keep UI layout as a function of usability only and your UI's behavior is streamlined with as little surprises as possible.

By experience users generally stop reading warnings after they become lightly acquainted with the interface unless you force them to.

I think, from comment, My answer deserves an example :

Take the delete button in Gmail web gui, it is easily accessible and bears no special marks from other options available, but the action is easily reversible so if clicked by accident it is easy to fall back to the original workflow and the disruption is, well, minor. So, will the Gmail interface benefit from making the button big and obvious or hiding it in a drop down ? no, quite the contrary.

If that same button, when clicked deletes all messages in the inbox by default then the difference in changing the gui and making it obvious or inconspicuous is literally dwarfed by changing the button's behavior to be more forgiving.

Of course this is a very broad answer for a very broad question, YMMV depending on the particular situation your interface demands. Nonetheless the answer holds true as most often this option will be part of the normal work-flow that can be performed in this particular gui and should be treated as such, no more, no less.

In conclusion, in my opinion, the only question that should apply in determining the presentation of the option is not it's effect but it's usability. If it is an option that is used often and part of the normal flow, make it prominent, if it is an option that is used only exceptionally then place it away in favor of more often used options.