Has anyone ever seen the following design pattern in use, and if so, is there ever a good time to use it?

(Button) labeled "Do Something"
[User] left-clicks on (Button)
[System] action A (Add) is performed
[User] right-clicks on (Button)
[System] action B (Subtract; inverse of A) is performed
  • 7
    I have not seen it and can't think of a good time to ever use it.
    – DA01
    Commented Oct 9, 2012 at 20:04
  • 3
    I've only ever seen these used in games. Well, sort of, for example in AOE, if you take the build unit button: Left click adds a unit to the build queue and right click removes a unit from the queue. Commented Oct 10, 2012 at 6:21

6 Answers 6


There are two problems with this:

  1. It is not compatible with touch devices.

    You may be developing for desktop eviroments, but that doesn't mean that the user doesn't use touch to interact with your application.

  2. It is hard to discover.

    When you see a button you know you can click it, because it visually tells you that you can click it (by having an icon, a bevel, distintive color or other decorations). And that is because we have seen this over and over, now a secondary function is less common and something that would be done only when the user doesn't know what to do, which makes it a good place to add some contextual help.

Now just think how irritated that touch user will feel when discovers about your silly button.

By the way, if you actually implement this, don't forget that the buttons of the mouse can be swapped.

  • 1
    Good point about touch devices. We should always avoid designing interfaces that assume that a specific input device is being used. Commented Oct 10, 2012 at 9:48
  • For the most part, touch devices tend to use a long-press as a substitute for right clicking.
    – Brian
    Commented Oct 12, 2012 at 20:41

Agree with discoverability issues. Illustrator application for example uses and "Alt" key to reverse the action (e.g. shape builder > click adds shape and alt+click removes shape). So, perhaps, you can consider a modifier key. Although, if your app is not something that your users use frequently and for long periods of time to do some repetitive tasks it would be better to go with another solution - for example, an extra button to do the reverse.


Related to the discoverability issue - users don't usually expect right click to do anything but open a contextual menu.

Case in point: recently I did a usability study of Windows 8 and IE 10. In IE10, you have to right click to show the url bar. Very few users (probably 1 in 20) right clicked, and if they did right click they were usually pretty surprised that it worked.


I have not seen it, and I don't think it aligns to the conventional 'meaning' of right-click.

Normally, the left-click performs a primary action and the right-click opens a dialog offering multiple actions - including the primary one. So, when a user right-clicks on a link in a browser, they have the option to not just open the link (the left-button action), but to open in a new window, save as a favourite, email to a friend and so on.

The other problem is that it makes options non-discoverable. I want to subtract an item, but everything says 'Add'! Users rarely right-click on buttons either on desktop or the web, so discovery will be poor unless users read how to remove items before operating the application.

As an alternative, you could look at checkboxes and toggle buttons (common on mobile). You could also look at simply providing two buttons or being able to switch the interface into a 'delete' mode.


I can't imagine that ever being a good idea. Assigning inverse actions to the same button can only lead to confusion an mistakes.


Paint.net has a similar design pattern. Not with buttons but with the selected tools. For instance, if you select the Zoom tool, left-clicking somewhere on the canvas will zoom in, while right-clicking will zoom out. Similar to what Photoshop does with Alt+click, as mentioned above.

(And it works great :) )

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.