I have four buttons on my interface that all look the same but don't all act the same. They are laid out like the example below.


download bmml source – Wireframes created with Balsamiq Mockups

Button 1 and Button 2 are a modified toggle switch of sorts. If the user clicks Button 1, then it will become selected. The user then has two options. If they click on Button 2, Button 1 will be deselected and Button 2 will become selected. If they click on Button 1 again when it's selected, it will turn off. The same behavior happens for Button 2.

Button 3 and Button 4 are standard on/off toggle switches. Click once to turn it on. Click on the button again to turn it off.

The problem is that since the first two buttons do something different than the second two, I feel like they need to be visually separated. My problem lies in how to separate them since they are somewhat similar in their functionality.

Is there a best practice for laying out buttons with different functionality?

  • 3
    As a side-note to the question, I've noticed some uncertainty as to whether a toggle button indicates what is currently happening or what will happen if I click the button. In my industrial controls job, we always used the "radio button" concept, even for Yes/No or On/Off controls, and completely shunned the toggle idea wherever possible except for checkboxes. What is currently happening was visually disabled and would not change anything if clicked again, and the other options were enabled.
    – AaronD
    Commented Jun 15, 2015 at 23:25
  • You can seperate them with color
    – BlueWizard
    Commented Jun 16, 2015 at 10:58
  • @AaronD You should check this question. It might help give you some answers ux.stackexchange.com/questions/1318/…
    – BDD
    Commented Jun 17, 2015 at 14:40
  • Yep, the accepted answer there and the highest voted comment on that answer agree completely with what I'm saying here. Toggle buttons are confusing; don't use them.
    – AaronD
    Commented Jun 17, 2015 at 14:56

8 Answers 8


Checkboxes are often used instead...

For these kinds of togglable, mutually exclusive options. For example:

enter image description here

But if you prefer buttons...

A check mark inside the buttons provides a better toggle affordance, and is also more color-blind friendly:

enter image description here

Radio buttons can also be used here for the exclusive buttons, but they (a) require an additional 3rd choice in the UI ("neither") which may or may not be acceptable; and (b) do not meet the click-to-toggle behavior specified in the question.

If you're willing to relax these requirements then radio buttons are an alternative too.

  • 5
    Checkboxes imply that one or both or neither can be checked. You can't have a car that's both 2-door and 4-door. If you want exactly one, you should be using a radio control. Commented Jun 15, 2015 at 21:16
  • 8
    @BlueRaja-DannyPflughoeft No. Radio buttons cannot be unchecked. The OP wants togglable state, so checkboxes are commonly used for this situation. If the user selects 2-door first, and then selects 4-door, the initial choice is automatically unchecked. The control island border provides the affordance that the two checkboxes are related. This example shows how it works.
    – tohster
    Commented Jun 15, 2015 at 21:21
  • 6
    Then neither radio-buttons nor checkboxes are not the correct control for his use-case. Commented Jun 15, 2015 at 21:25
  • 5
    @BlueRaja-DannyPflughoeft no that's not correct either. Mutually exclusive checkboxes have been used for a long time. There are clearer ways to do this by making the "neither" choice expicit, but mutually exclusive checkboxes are not an antipattern....they are used in large scale applications including Microsoft Windows and Office, Google Apps, etc.
    – tohster
    Commented Jun 15, 2015 at 21:27
  • 4
    Not an antipattern, but in my opinion not appropriate in this example either. Automatic unchecking defies my expectations of this control. Mutually exclusive checkboxes have merit if logical dependencies are too complex to be expressed in radio buttons or semantically if the interfaces poses multiple binary questions to which some answers exclude one another, e.g. Windows's NTFS permissions form. Here, the underlying question is not "Does it have two doors?" but rather "How many doors does it have?" Since answers are easily enumerated, I think radio buttons are the more suitable control. Commented Jun 16, 2015 at 11:05

I would join button 1 and button 2. Then you can have the one that is selected be a different shade than the other (for example, 'yes' is selected in the example below. When 'no' is selected it will become blue and 'yes' will become white). This will show that those two are mutually exclusive.

Then for buttons 3 & 4, I would use the same 'on' and 'off' colors, but leave them as individual buttons. Hope this helps.

  • 2
    This was my first instinct as well, but it has a small problem where users may not realize that "none of the above" is a valid choice or even possible on the segmented control. They are usually treated like radio buttons where you can only move the selection, you can't deselect something. Commented Jun 15, 2015 at 17:44
  • Ah, yes, I do see that now. Sorry about that. As suggested below you could add a third button to the group for 'none.' Commented Jun 15, 2015 at 18:07
  • Maybe I'm off with this, but couldn't you group the first 2 buttons in a select menu? 3 options: button 1, button 2, none? Commented Jun 15, 2015 at 18:20
  • 9
    As a user, I actually hate the light/dark switch paradigm pictured above when there are 2 options because it's not immediately clear which color is "selected". With 3+ options, it is clear, but with only 2, it is ambiguous. Some visual changes could eliminate the ambiguity, but as pictured above it confuses.
    – Marsh
    Commented Jun 16, 2015 at 16:23
  • Yes, I would agree with that. A visual indicator such as an icon would be helpful. Commented Jun 18, 2015 at 13:37

For what I see, you actually have 3 buttons (= actions).

Button 1

Tri state button/toggle:

Button 1 reacts to itself and Button 2

Button 2 reacts to itself and Button 1

Button 2

Boolean button/toggle:

Button 3 reacts to itself (YES/NO, ON/OFF)

Button 3

Boolean button/toggle:

Button 4 reacts to itself (YES/NO, ON/OFF)

Basically, you have 3 actions, in which the first one is an action group with child actions that interact with the same boolean logic as the other: yes/no, on/off, 1/0

A valid cultural reference is the old tape recorders, where you had pause buttons that interacted by themselves, then the play and record buttons that had to be pressed together, then rewind and forward buttons that canceled each other

enter image description here

So, the proposed solution is to group the first 2 buttons and use a tri-state toggle since they interact between them, leaving the remaining buttons isolated but still part of the process. See a basic mockup below:

enter image description here

As you may see, now all buttons are selected by themselves, while buttons 1 and 2 are clearly connected as part of a same action group but we also added a 3rd state (off), in which you can cancel both sub-actions (button 1 and button 2) at the same time

  • That "valid cultural reference" you speak of is an example of actual radio buttons hence the name.
    – zzzzBov
    Commented Jun 15, 2015 at 21:20
  • as a matter of fact, I'm not speaking of that, I'm speaking exactly of what I'm showing in the picture: a cassette/tape recorder, where there are different behaviors for each of the keys. I deliberately left out the word radio to avoid any confusion: a radio button is, by definition, exclusive of other options, thus the exact opposite of what the OP wants, where keys can be selected and deselected besides excluding other keys
    – Devin
    Commented Jun 15, 2015 at 21:31
  • in terms of html, these could be achieved in different ways, but the most common is a checkbox input, not a radio
    – Devin
    Commented Jun 15, 2015 at 21:32
  • 1
    Why do you go from a picture of a row of identical keys on a cassette player ( all keys look the same, are spaced the same and the related record and play keys are not together ) to a suggestion of making the buttons look different have significant spacing and be grouped together with related buttons with 'so', implying you'll draw inspiration from one to get to the other? Commented Jun 16, 2015 at 22:44

You should try creating a grouped button control. Something like this:

Segmented button

When a user looks at the grouped buttons he/she may not immediately understand which one is on and which one is off, so you should add some color (active = green). If you think that this is not enough and if your design permits add some depth in order to eliminate any doubt when it comes to which one is selected.

Button depth

If you don't like this maybe you should group them in a group control (line out the group) something like this:

Grouping buttons like in Microsoft Office suit

I hope this helps. :)


A cyclical button may be your best choice.

I have doubts about segmented controls since they traditionally match the mental model of radio buttons: one choice must always be selected. You could add a "None" option, but that could increase the clutter and confusion on the toolbar.

A three-way toggle may fit your use case better.

Animated button cycle.

It isn't a very common pattern as it doesn't allow a user to see what the other options are, nor how many there will be before it loops back around. Additionally, if there is a performance cost each time you change the filter users who "miss their target" could become annoyed at the time it takes to cycle back around to the correct choice.

But, if the context is limited to only 2 mutually exclusive modes that your typical user will understand in context plus a neither mode this option could be very functional for you. Something like a filter that shows "Active Widgets", "Inactive Widgets", or "All Widgets" should be simple enough for users to understand what they are seeing.

Depending on how the other standard toggles look, this control may raise the classic debate over state vs. action labels.

  • Depends on the context, but I don't like this solution because I can't see all the options available. Users are not used to having a toggle have more than two states. So you see one state "Neither", click to change to "First Mode" and you might expect your choices end here, as they typically do.
    – ecc
    Commented Jun 16, 2015 at 20:46
  • 5
    This has the problem of confusing the current state to the option that will become chosen on next click.
    – frozenkoi
    Commented Jun 17, 2015 at 0:53

Is there a best practice for laying out buttons with different functionality?

Let's get back to this in just a little.

First, let's look at (emphasis added):

I have four buttons on my interface that all look the same but don't all act the same.

So you've asked a question about layout, but at the core the real issue you're trying to address is how do we create cues for control interaction.

Layout is definitely a key way to denote particular elements of control interaction: most specifically and frequently, semantic relationships to affected processes.

Can layout also be used to address differences in control behavior?

Let's go back to basics.

How do we learn how a control works, functionally?

First, we examine it. What does it look like, what does it remind us of… essentially, what does it seem globally consistent to, visually?

Even if we have no external references to figure out how a control should function, we can still try playing with it. How does interacting with the control change its visual appearance? Does interacting with Control A affect any other controls? Is there a consistent difference in the appearance between the controls that affect the operation of other controls, versus those that seem self contained?

Every time we recognize a pattern, we attempt to re-apply that when interacting with something that seems to meet the same pattern. Essentially, we form a schema and adjust it as needed, usually with a preference for fitting seemingly new things we see into our current schema (assimilation). This is what allows us to quickly allow current models of interaction to apply to scenarios where something appears slightly different but seems to adhere to the overall pattern.

A good example is a toggle switch. We quickly recognize the exclusive state binary behavior of such a switch because it's modeled after switches that are used physically, where if such a switch is toggled in one direction, it physically can't be in the other state. While it would be easy to consider the visual look of most toggle switches to be simply skeuomorphic, they're actually important visual references that are globally consistent and consistent to the physical behavior they are meant to serve as cues for.

Now, let's try something a little more interesting.

What is the difference between a group of radio buttons and a group of checkboxes?

If each group is bounded in a box, how do you, as someone trying to achieve a result, know how each group will interact to that end?

  1. Global consistency and prior knowledge within similar contexts (software/web): We know how each group will interact because we know from prior control use in other places that a round button denotes linked, mutually exclusive states between it and other buttons in the group, and a square one denotes independent states, even if each one is semantically or otherwise related in some other way (thus the grouping).
  2. Related (global) knowledge from different contexts: we may have seen a physical device using radio buttons (such as, say, older radios they derive their name from). We may have done tasks that involved physically (pencil/pen) checking off choices or filling in circles (scantron, etc) where similar paradigms are frequently adhered to.
  3. Discovery through Exploration (learning specific to this interaction, but carried out with expectations from prior learning): when we play with the round switch buttons, selecting a different one de-selects any previously selected. We can infer that this is behavior common to these because they visually appear different from other controls, but appear relatively the same within the same type of control. This behavior doesn't happen with the square switch buttons.

So what happens when all of the buttons are round, but one group acts like radio buttons and the other like checkboxes?


We can no longer rely on our current schema to provide meaningful information, which means we have to test every set of controls to see how it works. There might be cues provided, but the inconsistency with what we already know and how we're already familiar with interacting with the world will cause degrees of frission even then: essentially, whether consciously acknowledged or not, this creates a state of cognitive dissonance that is taxing and frustrating. Even within a common task set (a single form, application, etc) the conflict will remain for quite some time, before the specifically different knowledge can be partitioned to applying exclusively within that task domain.

So what about layout?

Well, the problem is that layout exists at a level wider than that of simply the control itself. Visually, layout is a secondary signifier to the control's action or import, compared to the control's own design.

Differences and similarities in how the control itself looks will always take precedence in how someone interacting with it interprets its anticipated action behavior.

Failure for the control to function in anticipated ways will cause frustration when the control behaves differently from what was expected.

Failure for the control to function in anticipated ways will also cause hesitation throughout the task domain: the person interacting with your software is no longer able to rely on being able to differentiate simply by looking at the appearance of the control itself.

Hesitation is in turn frustrating.

In short, as an answer to the question asked within the question body:

Don't rely on layout to signify different behavior between otherwise visually identical controls

In terms of different control designs, I think a number of the options proposed have promise.

Using a dropdown for a ternary state control is not a bad idea.

Using a connected three way "switch" control is also, in my opinion, not necessarily a bad idea. I would caution that it might become unwieldy depending on the text used.

Using a two way switch control may be problematic, as they are usually expected to be binary: an exclusive or where one must be selected and the other is thereby deselected.

Do use layout to group controls based on what they affect

Placement is helpful for mapping to affected objects not only physically (e.g. placement of controls on a stove), but also at more abstract levels.

Placement and grouping are also helpful in separating out controls from other objects competing for attention, which can be useful in reducing stress of trying to process what otherwise might be neighbor controls for possible relationships in overall functionality.

Slightly more simply, if the immediate concern in what a set of controls affect is limited only to those controls, it can help to separate out those controls either via distance or via visual cues (separating lines, bounding boxes, etc).

Just be careful that you don't accidentally mix cues up with other possible interpretations that create needless confusion (for instance, if placed too close between two controls, a single vertical separating line can sometimes look like it instead denotes a binary switch state for the controls it rests between).

I think layout could be used to your advantage here, but I feel you must first address the appearance of the controls in some way that creates a definite visual cue differentiating those which have disparate action behavior.

If all of these apply to essentially the same object/aspect being affected, just in different ways, I would however advise keeping them grouped together if possible, to retain that significance, especially since it is only 4 (or 3) separate controls.


Unless the button texts are confusing, i would go with BDD's suggestion of having buttons 1&2 joined. if the button labels do. It suggest they can be cleared I would add text 'clear' somewhere near the button row, when a button has been selected. Not before. And text 'clear',not 'none' or fri-state buttons, those might be confusing.


Wouldn't a radio button giving the 3 options ("Option A", "Option B", "Neither") be the most appropriate for the first group? I know they aren't as 'sexy' as buttons, but it seems to me that that's what you're trying to force a different achieve input type in to replicating.

The other two are checkboxes.

I'm sure there's some visual design requirements, in which case you might want to style them appropriately, but sticking with standard HTML elements where possible keeps things accessible to all - eg those with screen readers, JS turned off, etc etc.

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.