When a user wants to remove something we tend to protect them by:

  • asking for a confirmation, yes | no
  • giving them an option to undo

This holds up for content that actually gets deleted. An email you delete, or trashing a photo. But what about less critical actions? Like removing a tag from an article, or un-friending someone? In such cases no content gets deleted, it is just a relation which is not there anymore. But adding it again is trivial.

One approach is to not guide at all. Just a red cross, and clicking it removed the tag from the article. Are there any ways to guide users in this? (Except for making it easy to re-create it.)


How about providing a brief message that's displayed right after the action, giving you a chance to reconsider? "You un-friended Jack. You will no longer receive updates from him. Undo?" If the message doesn't open a dialog but appears on the page itself, and it disappears automatically a second later, then it can be very subtle and non-interfering. This is a bit different from "making it easy to recreate it", because it's closer to "having never un-friended Jack in the first place" than to "re-friending Jack". It may even cause different behaviors - like not really un-friending Jack until the immediate undo option had disappeared.

Alternatively, you can prove this info on hover/tooltip on the button, before the action is performed.

  • 4
    I like how you combine it with explaining the effect of the user's action, as in "you will no longer receive updates, undo?". – Lode Mar 9 '11 at 16:01
  • The more I think about it, the better it is. This way, it also turns a 'delete' action into a 'normal' action (nothing "bad"). It is just something you do, a normal part of this application. Thanks for the insight! – Lode Mar 14 '11 at 6:42


If that's possible in any way, offer a decent undo function of the operation of the current session / page. In the last decade, the user model has changed from "the user reads the manual and knows what he does, generally" to "the user experiments until he figures out how things work".

This is not always possible depending on the data involved (or restrictions). But for these minor changes, this certainly applies.

You can embellish that by a non-modal bubble / info bar to indictae the undo functionality to noviceusers (with an option to disable these, of course). I would do that only for applications / environments where undo is unexpected or not supported for all items.


Even better (but requiring even more work) is a diffable history, that allows the user to at least see the old data, so it can be recreated.

For your examples: A "tag history" or list of "ex-friends" might even you to "retag" or "re-friend".

This requires to retain more data, both in amount and complexity. But the end user experience is miles better than "Do you really want to remove this tag?"

  • 2
    +1 Also, you can differentiate between the general "history" functionality and the undo of the last action specifically, by making it seem like a separate action. Like Chrome does with the action "reopen closed tab" which is separated from the general "history" list, though it's basically just taking the last item from the history. – Vitaly Mijiritsky Mar 9 '11 at 15:06
  • It has something nice, but I fear it depends on a lot of technical work and discovery by the user. Also, I question if it is interesting for every kind of website to be able to undo actions taken long time ago. For a text editor yes, for un-friending, no. – Lode Mar 14 '11 at 6:44
  • Depends on your app, for sure. But in that example, I figure "looking for that guy that once was on your friend list" isn't that unusual (and encourages keeping the friend list clean). From that, it's only a small step to re-add. – peterchen Mar 14 '11 at 13:43

We talk about “destructive” actions like Delete and Remove as if they were in a special class requiring special protection. In reality, nearly all actions both create and destroy. Changing my document view for Print to Outline “destroys” one presentation of information for the sake of another. The question to ask is, “how serious are the consequences if the user does this action by accident?” Accidentally adding an unwanted “friend” to a list can be just as bad as removing a wanted “friend.”

The guidance you’re looking for is:

  • The user should be able to reverse any discrete action with the same or less amount of work it takes to complete the action.

  • If there is a clear means to reverse an action that takes less than 20 seconds of work, then the action should not have a confirmation.

  • If it is technically infeasible to provide a means of reversing an action with less than 20 seconds of work, then the action shall have a confirmation.

Reversing an action may mean selecting Undo, and that is certainly a good way of doing it. However it could be any clearly apparent way to reverse the action, including redoing it from scratch. If the user can add a friend in 20 seconds, then removing one should not have a confirmation.

Note this means that confirmations tend to be overused. It doesn’t matter that the user is deleting a 500-page novel that took 3 years to write. If it can be recovered by pulling it out of recycling (or hitting Ctrl-Z), then it doesn’t need confirmation. Personally, I run Windows Explorer with Delete Confirmation turned off, and I’ve yet to regret it.

This applies to all actions, not just destructive ones. Should you confirm exiting the application when everything is saved? If re-entering it means merely double-clicking an icon and scrolling, no. If it means going through an elaborate 45-second login process, then yes.

What’s so special about 20 seconds? It takes about 2 seconds to click a confirmation. I figure that 10% of all actions are errors (that’s probably being generous). If you add a confirmation to an action that takes less than 20 seconds to reverse, then on average you’re creating more work than you’re saving the user.

Add to that the fact that confirmations often don’t help the user anyway. Misuse and over-use of confirmations has trained users to dismiss then out of habit, usually without reading them (I’ve more on that at Of Dialogs and Detritus). Furthermore, often users don’t realize they’re making a mistake until after the action is committed and they see the results. Confirmations are primarily good for catching slips of the mouse or finger. Otherwise it’s better to provide:

  • Clear indications of what each command does.

  • Clear and immediate feedback of consequences of each command.

  • Clear and fast means to reverse the command.


The label on the button/link is your best guide. An x could be a bit confusing because is could mean "close", "hide" or "delete", so maybe rather use words. Whatever you do it should not add additional load on the user (so a dialog is out of the question). If the user is doing something simple and non-critical, there is no need for long explanations which won't be read anyway.


It seems we all agree here. I did not know, until I reasoned like this:

It's about removing something non-critical, and the assumption that Lode puts there is: the user WANTS to remove it. If this assumption is true, than the necessary act for removing must be made clear (like the X, or the mouse-over "remove" or something) and that should be enough guidance. However, the assumption could not be true: the user does not want to remove, but nevertheless he comes to do an action that would have removal as a result. Now here the same X or "remove" text will work as a warning. And since the removed item is non-critical (in Lode's question), that should be enough guidance as well.

  • Thanks. It depends a bit on what it is about. A 'remove' label won't always fit, for example, when removing tags; there are too many to show 'remove' after every of them. Also, this does not allow for the user to play around and experiment with the interface without being 'punished' by the system because they deleted something and are left alone in the dark about what happened, how bad or not it is, and what to do to recover. – Lode Mar 14 '11 at 6:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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