I have a quick question about buttons that toggle between two states. (Think Play/Pause, or Shuffle/Regular Play.) As the title says, should the toggle show it's current state or the state to which it will transition?

I think people are used to the Play/Pause convention. But the Shuffle/Regular play might be more confusing if you show the transition state instead of current. For example, the built-in music player on the Xbox 360 does it this way: when it's in shuffle mode, it shows the icon for direct play and vice versa and it always confuses me (am I in shuffle mode or straight play).

I see it this way: Play/Pause is more like action as in begin playing or pause playing. Yes behind the scenes it is a state transition but to the user, there is an action. Whereas Shuffle/Straight Play is an option and it's best to show the current state (and possibly have only one icon and change button to show that the option is enabled/disabled). Thoughts?

  • 7
    What about using a checkbox, especially if the selection between the two options can be summarized in a yes/no question?
    – vsz
    Commented Feb 21, 2013 at 22:44
  • long time ago, but - I'd stay away from these categories (action vs. option). I'm surprised at how often I think these are clear, and "my" users have never thought about them, much less a clear distinction. Commented Dec 12, 2013 at 12:20
  • Only a comment but I put the text Mode: in front of all toggle buttons and make them a different color. It is less space than radio buttons. I use it when the toggle needs to be in a certain orders
    – paparazzo
    Commented Oct 20, 2014 at 19:19
  • 2
    Stupid points requirements. Can't do a full answer. Poll of major media players on Windows/Android/Linux platform says: play/pause button shows the action, all other state buttons show current state. Every major media player does this. "Fixing" the play button yields a dissonant UI that users will raise bugs against. User have been strongly conditioned to expect the Play/Pause button convention. If you're designing a media player UI, you should follow the broken convention. You can avoid the conflict by providing both a play and a pause button. (No major media player does this) Commented Feb 12 at 16:39

24 Answers 24


In About Face 2.0 (there is a v3 but I haven't got it) Cooper and Reimann (2003, pp. 341-2) treat this subject under the heading "Flip-flop buttons: A selection idiom to avoid". I strongly suggest to consult this book as I will only present an excerpt:

Flip-flop button controls are very efficient. They save space by controlling two mutually exclusive options with a single control. The problem with flip-flop controls is that they fail to fulfill the second duty of every control - to inform the user of their current state. If the button says ON when the state is off, it is unclear what the setting is. If it is OFF when the state is off, however, where is the ON button? Don't use them. Not on buttons and no on menus!

The authors (and I think of these as an authority on the subject) presents two possible solutions: You should either spell the button's action out as a verb phrase (e.g., Switch to portrait mode, thereby sacrificing some of the saved space) or use some other technique entirely (e.g., two radio buttons).

  • 13
    It's page 445 of About Face 3. Commented Sep 7, 2010 at 12:50
  • 7
    I hate these buttons. Commented May 31, 2011 at 3:10
  • 151
    We have an industrial control process with flip-flop buttons everywhere. Whenever things are running, they are RED to indicate that it will stop if you push the button. If it's stopped, they are GREEN. It's the most confusing UI I've ever seen. A screen full of red means everything is running smoothly! o_O
    – Andy S
    Commented Oct 25, 2011 at 18:28
  • 40
    @AndyS: Nope, a screen full of red means "Don't you f*ing touch anything here!" :D
    – SNag
    Commented Jun 15, 2013 at 15:59
  • 19
    Relying on red/green alone doesn't make for great accessibility, either. Commented Jun 24, 2013 at 13:14

Short Answer:

Quite a late answer, but I'm surprised no one here pointed this out before -- it is possible for a toggle switch to show its current state and the state to which it will change simply by having text outside the button, instead of on it.

Real Life Switches

Long Answer:

As dotancohen points out:

The problem is that in English "on" and "off" are both adverbs and adjectives.

Buttons that have text outside of their body use this very fact to their advantage! Read on...

Take the iOS switch design:

iOS On-Off Switch

Let's focus on the state that's blue and says ON for example.


Can you tell if the switch is ON currently, or if it will go on if you move/click/tap the slider? Is the text obvious? Is "ON" here a state(adjective) or action(verb)? Unclear. Is the color of any use to help you decide this? Probably, but not certainly -- iOS users may be habituated to the states of this design, but there's no telling how non-iOS users would interpret this. To see what I mean, take this real life trip-switch, which has the same design as the iOS switch -- can you tell for sure if the trip switch is currently ON?

Ambiguous Trip Switch

The switch below is along the lines of the iOS design, but far worse...

Ambiguous On-Off Switch

...it's not even clear which half the slide/click handle is!

On the other hand, the OS X switch design leaves no room for ambiguity:

Unambiguous On-Off Switch

The question from jensgram's quote...

If the button says ON when the state is off, it is unclear what the setting is. If it is OFF when the state is off, however, where is the ON button?

...never arises here since the button neither says ON nor OFF -- it just stands by itself. Also, there's no confusion about the context of the words ON and OFF -- they are very clearly states (adjectives) since clicking on them (in the normal design) would do nothing!

It may be interesting to note that a modification to this design would allow for the text on the far side of the button to be made click-able/tap-able. If so, the word closer to the switch-handle is the state, while other one is the action, and the roles are reversed when the switch is toggled.

Modded On-Off Switch

Even so, the user's perspective of the switch isn't altered -- at no point is the user confused about the current state of the switch. In fact, the design could be further enhanced for user friendliness by highlighting the current state:

Highlighted On-Off Switch

The Windows Metro UI design for the switch goes a step further, and removes the "action" text from the button, and retains just the "state" text:

Win8 On-Off Switch

The color of the button indicates the current state (lit up = ON, as in real life), and the words On/Off underneath the option text reassure the user of the current state.

  • 16
    Nice answer especially considering the time lapse! Commented Jun 17, 2013 at 22:07
  • 7
    Good point about having the text outside. Just want to point out that it's not about on/off being verbs. On/off are certainly not verbs (guess they could be adverbs - "to turn OFF/ON"). It's about the perception of buttons doing things when you click on them. And as the text on buttons usually say the action to perform and not the opposite of the state you want to go to, it can be hard to tell what the button actually does.
    – Jonathan
    Commented Feb 27, 2014 at 0:56
  • 4
    Excellent point. Surprising to see OS X get it right while iOS is a bit ambiguous.
    – tbolt
    Commented Jun 26, 2014 at 13:34
  • 4
    The outside labelling works for me. The only caveat I'd add is that the total length of the "slide area" must be clearly more than double the size of the button. The first example, below "On the other hand, the OS X switch design leaves no room for ambiguity", just achieves this, but I've seen examples where the slider is exactly half the width and it can be very difficult to tell which half is the slider.
    – TripeHound
    Commented Apr 24, 2015 at 16:00
  • 1
    One of my favorite answers on stackexchange. Are there any more compact options without sacrificing clarity? I.e. what if you showed the current stay: active, paused, then on hover showed a popover with the toggle you have suggested.
    – ckarbass
    Commented Jun 23, 2015 at 22:12

Whatever you decide - please don't do what twitter does.

Aargh don't change the button when I'm about to click it!

  • 31
    I don't think it's a bad example, the effect on mouseover gives enough information to understand how it works. But it may still be confusing on a touch screen, without mouse hover. Commented Feb 21, 2014 at 11:27
  • 14
    @n.1 Typically you wouldn't mouse over and stop if there was a change of state, you would go in and click with one intention and all of a sudden the button flips on you hoping you will pause long enough to recognize the change. Mostly this results in accidental clicking more often than not. Commented May 11, 2014 at 1:39
  • 57
    +1 for the very shy mouse that seems apprehensive about clicking the button.
    – user31914
    Commented Aug 29, 2014 at 5:26
  • I just wanted to suggest this idea. What Twitter does looks like a perfect solution to me. What is important is to see the current status. The action to change the status should be discoverable, but the indication does not need to be shown permanently.
    – Alexey
    Commented May 1, 2022 at 10:02
  • This isn't bad, unless the user is on a touch device instead of a device with a pointing device like a mouse. Commented Feb 13 at 18:51

The problem is that in English "on" and "off" are both adverbs and adjectives. Therefore, find replacement words that are either verbs or adjectives to label the buttons with:

Enable / Disable
Enabled / Disabled
Start / Stop
Running / Stopped

Very late edit: See this terrific switch that a coworker of mine designed, which succeeds in keeping the "on/off" terminology yet does so unambiguously:

on off switch

  • 1
    It doesn't answer the subject when you have switch button to toggle SIMPLE VIEW/ADVANCED VIEW where the simple view is the full table of contents (tree view) and advanced view is the table of contents with only nodes which are opened. Commented Jun 11, 2013 at 5:55
  • 4
    "On" and "off" are certainly not verbs, though I suppose they might be interpreted as abbreviations for phrases like "switch on". In any case, the distinction between labelling a control "enable" or "enabled" is too subtle to make for a clear, usable interface. Commented Dec 18, 2013 at 21:54
  • 1
    They are also prepositions. Commented Sep 30, 2016 at 19:59
  • 2
    Is all this complexity really needed?
    – invot
    Commented Dec 2, 2016 at 17:00

A reasonable compromise would be to have the button not highlighted (have a neutral background color perhaps) when it is on the off state, and highlight it (change background color) when it is in the on state.

For example, looking at this screenshot of the Spotify (web)app, do you think shuffle is on or off?

Shuffle is most certainly on

  • No. In a music player, the music it self or the seconds ticking is showing the state. Thus a toggle button for save pause is acceptable. Believe me, we tried with pause/play buttons for active items in an app once, and it was very confusing since you never knew the state. Was solved with a tooltip of "click to pause subscription", but I would avoid this at all costs. Commented Jan 26 at 14:32
  • 1
    @JoakimPoromaaHelger The answer isn't about the pause/play button; it's about the highlighted shuffle button.
    – mbomb007
    Commented Feb 12 at 15:36
  • It works if and only if one of the buttons is "on". Redo the bitmap with the shuffle button in off state, and ask the same question. This is particularly relevant since, the default state for the toggle controls should be all buttons off. Note that he UI is not only ambiguous, but dissonant, since Spotify uses the opposite convention for the Play/Pause button. (That being said, this is the convention that pretty much all major media players use. Commented Feb 12 at 16:07

I think you've got it pretty much right in your question.

If the toggle is an action - Play/Pause - then it should show the thing that will happen. So while paused it would show Play and then while playing show Pause.

If the toggle is an option - Shuffle/Linear - then it should show the current state.

How you indicate that to the user that one button is an action and the other is an option I'm not sure...

  • 3
    Perhaps buttons that perform an action and have their behavior toggled when clicked should not really be considered Toggle Buttons but instead just regular buttons that have their behavior dependent on the action that is currently being performed.
    – jpierson
    Commented Feb 7, 2011 at 17:42
  • 1
    This is the perfect answer to my similar question. Commented Mar 17, 2014 at 17:01

There's already 18 answers here so this might be late to the party, but it makes sense to use checkboxes in such situations. Some examples:

enter image description here

And when selected:

enter image description here

This is similar to the "dim / lit" approach that Facebook's "Like" uses, but is combined with a checkbox for better visibility. In any case, the key point is to use only one word (or set of words) instead of trying to make the user decide between multiple words.

Also, make it a point to avoid using negative prefixes ("Not", "Non-", "Un-", "Dis-", "Im-", "Mis-", "In-", "Il-", "Ir-") otherwise the user would then have to do a "double negative" in his mind when he had unchecked the checkbox:

enter image description here

  • 5
    That's not a bad answer. No, not at all.
    – user67695
    Commented Mar 28, 2017 at 19:32
  • I think a major reason to not use negative prefixes is they imply only an action and not a state. In your example, "unbold" implies removing any bold that is applied, not prevent bolding from ever happening. What does it mean if "unbold" is checked? Who knows?! Commented Aug 26, 2022 at 14:48

I would say that it depends on the case, as ChrisF said, it's important to have a distinction between an action button and a state button.

If your button has text, you could change the text to show that clicking it will do something (ex: "Turn shuffle play on"). However, in your case, since it's only an icon, I would go with only a shuffle icon that looks enabled/disabled depending on the state. If it's disabled, then it should be clear to the user that it's straight play. You could light it up or show the button as pressed down.

Consider adding a tooltip on hover to make it even more clear.


I'd stop just short of "don't use them."

I'd suggest toggle buttons are acceptable in the case where there is a clear on and off state. This can occur, for instance, when you have a line of grayed buttons that become colored when you click them.

This is the reason Play/Pause works in many cases. The play button is not so much a toggle between two states as an enable/disable. It turns bright green when on (I'm playing!), it turns gray and shows a || when off (I'm not playing!).

The other buttons do the same, so the consistency adds to the affordance. It's probably also based on our historical perceptions of a tape deck or VCR, which had buttons you pressed in (i.e. on state) or depressed (i.e. off state) and I think this is a great mental model to keep in mind when considering a toggle.

But in any case where they are not simply "activated", where you couldn't replace the toggle with an uglier checkbox, I'd default to "don't use them," for all the reasons already mentioned.


I just noticed today that Evernote has a pretty effective toggle. They took the approach of a mouseover, which actually worked pretty well. Note that this is another case of an on/off style control.

toggled off

toggled on


I found this interesting switch today and was reminded of this UX Q&A. Note how the state is immediately obvious, and the fact that it's going to switch when you touch it is also made obvious by the textured "handle" (i.e. affordance)--I just know that when I grab that raised knob, it will switch to the opposite side and say the opposite of what it says now; it's just like an airplane lavatory.

So they can be done well.

toggled off toggled on

  • 6
    Looking at your right "lavatory" button, I tend to move it to the left to switch it "on".
    – maaartinus
    Commented Oct 19, 2014 at 18:47
  • 2
    For a lavatory, green usually means "you can walk in!" and then you go in and know that you must lock it, whereupon it turns red, indicating that it is "locked" and also, "you can't go out". But you know whether you have gotten in or not so the state is obvious. In cars, the lock lever tends to show red when it is unlocked, meaning perhaps "unsafe"? I find this irritating. The only safety in locking yourself inside is if someone walks up to the car. On the highway, you want it unlocked so that you can get out and people can help if there is a crash. So, red / green is problematic for doors.
    – user67695
    Commented Sep 6, 2016 at 14:41

I'm surprised to see no mention of the technique used in iOS (and elsewhere), a combined action/state button, where both options are visible, grouped and the active one is clearly highlighted.

Terrible ascii art to demonstrate:

[ ON | off ]

Airplane mode toggle on iOS

  • 61
    I believe that iOS switch is a total failure. Look at the image on the image provided in the comment above and try to answer the fundamental question. What is the current state?!
    – Denzo
    Commented May 23, 2011 at 8:19
  • 9
    And when it is on it is a blue "On" on the left side. This is the opposite of a total failure. It is briliiant. Commented May 24, 2011 at 17:59
  • 36
    I find that utterly incomprehensible. If it's off "because OFF is the only thing visible," then do I turn it on by clicking the OFF button or the empty space to the left of it? Commented Aug 1, 2011 at 23:04
  • 11
    @Adrian: Exactly what jensgram said: "If it is OFF when the state is off, however, where is the ON button?" I think jezmck was right in the original post: Show both states, and highlight the active one.
    – l0b0
    Commented Nov 17, 2011 at 15:24
  • 7
    @l0b0: With only two choices, it's very difficult to show two options and highlight one in an unambiguous way. Is it highlighting off because the state is off because the only thing I can do is turn it off? I look at the Airplane Mode graphic above and keep thinking it's on because OFF looks like a button, and buttons should be labeled with the action they perform. Commented Nov 17, 2011 at 22:16

I have been using Toggle Button to "Add" and "Remove" elements to a collection using simple Toggle Button (one with state visible at a time) which had following states.

  • ADD (if button wasn't clicked ever)

  • REMOVE (if the button was previously clicked and an item was now part of the collection)

BUT this always pinched me as for a novice user (age 50+), it was initially hard to understand what has happened and why is button asking to "Remove" even before I learned that item was now part of the collection. The missing bit in this case was a notification message which would say "Item Successfully Added". I am using a Javascript Based Status Message which appears on the top of screen (using http://twitter.github.com/bootstrap/javascript.html#alerts) but since it was visually displaced from the element of interaction, I only solved a part of the problem for some users.

Another Issue

Your button changes its "Stance" or "Flips its sides" after every click. Sometimes it says "I am the add button" and some times the same button (in the same column among other add buttons) it says "I am remove button". Changing colors help but these are still two opposite roles taken up by one button. NOT SO RIGHT.

My Solution:

My solution to this minor and well discussed issue is to replace the toggle button with something like that.

Button which has Caption "Add" when not clicked After Click, Button replaces itself with a message "Successfully Added" and shows a small 24x24 button which has label "X" and which allows you to cancel your last act which is always "Add". Thus you never click a "Remove" button but only "cancel" your previous "Add Operation". Also you don't need to show a separate "Successfully Added" notification on the page. Down side of this approach is that that you need more space to put "Successfully Added" label and a "Button to Cancel" but this in my opinion is one of the less confusing approaches.

enter image description here

  • 1
    What if you start with a state where some things are already present (possibly added by a different user or a long time ago)? Do you show a mix of Add / Remove / Added to my list[X] / Removed from my list[X]?
    – maaartinus
    Commented May 18, 2014 at 4:56
  • 1
    Toggle button has two states. If you had to introduce a third one, for example add/remove from "global-list" and add/remove from "my-list", I would group two toggle states visually together and place the third button "add to my-list" button next to them. As a UX designer, you can consider simplifying user-flows and interaction rules. If you could separate "my-list" interactions from "global-list" interactions, that would be the right thing to do. Commented May 23, 2014 at 1:04

I would recommend watching the following video (from 1991!) which was seminal to the current design of the iOS toggle for instance: https://www.youtube.com/watch?v=wFWbdxicvK0

And corresponding paper: http://dl.acm.org/citation.cfm?id=143079

Here are the toggles they compared: The toggles they compared And the results in preference: Results of the preference test

  • I wonder what the results would be if "on" and "off" were reversed in all the switches. For modern platforms that use a two-label convention, the "Off" option always comes first. Commented Feb 12 at 16:26
  • It would be interesting to see this redone looking at accuracy when the labels were something a bit more specialized than "on"/"off". Have the user pick between different states that don't so obviously have a negative (evaluate discovery problems) and to include more than one button in the UI. And to avoid already known UIs that the participants would be familiar with. I don't think the 1-button control would fare so well.
    – lamont
    Commented Feb 14 at 0:22

In many cases it might be useful or possible to avoid such buttons.

E.g. in the case of shuffled/regular play: just use a checkbox with a "shuffle" label next to it, and nobody will get confused...

And in the case of a play/shuffle button, it's maybe not necessary to change the label on the button either. You could use a "pressed" button to indicate "playing", and an "up" button to indicate "not playing". Or you could put an indicator somewhere else in the UI of course (that's what my stereo system does...).

It's not because some company starts to use a certain widget that all of a sudden it should be used for everything...

  • 2
    It is widely accepted that CheckBoxes should not perform Commands. As for the lighting up up of a toggle button, I do agree with that. msdn.microsoft.com/en-us/library/aa511452.aspx#general
    – jpierson
    Commented Feb 7, 2011 at 17:38
  • 2
    In this particular case, the check box is not performing a command. Rather, when checked the music player should select a random song after this song ends; when unchecked the music player should proceed to the next song in order. Checking the box changes program state, but does not have an immediate "command" effect. Commented Feb 10, 2015 at 22:21

On Facebook, the like button is a good example for a toggle button.

On Facebook's Android app, the like is on a button and it's a grayed when off and highlighted blue when on. See screenshots below.

Basically, I agree with them - emphasize the positive and don't mess with users' brains (minimum change).

I'm not sure if it's a good way for color blinded. Perhaps they should have done the indication more bold.

enter image description here enter image description here

On Facebook's web-app, the pattern is different. The button's text changes to indicate the action - what happens on click. This is confusing. BUT, this makes sense because they have a lot of space and have a separate indication that a user likes a post.

enter image description here enter image description here


Labelled buttons (toggle buttons) are often confusing or even ambiguous, as you point out. Instead,
show the status and the action, like this:

Online   Go offline

So we have a non-clickable label clearly indicating the current status, and a clickable button to carry out an action to change the status.

If you click the "Go offline" button, then the label changes to "Offline" and the button changes to "Go online".

Showing both the current status and the action at the same time is the only way to be completely clear. Radio buttons would do this, but the label + button solution is better because it offers a clear visual distinction between the two. Also it is naturally more compact than radio buttons.

As for the alternatives, I think it's agreed that toggle buttons can be problematic. Even checkboxes may be confusing:


The checkbox is not checked, so the application is offline. But this isn't particularly clear. If you glance at it, the first thing you see is the word "Online", so it's easy to draw the wrong conclusion.

The trouble is that all you can see is a single label. You have to think for a bit before you can decide whether the label indicates a status or a command. This problem is common to checkboxes and buttons, and trying to consistently use adjectives (or verbs or whatever) may improve things but will not make the problem go away.

  • Checkboxes are good when actions can manipulate state directly and instantly; the problem with the "Online" checkbox is that it has no standard and unambiguous way of showing "Connection requested and in progress" or "Disconnect requested and in progress" states. The "verbs" approach can handle that if the "Go offline" button changes to a "Going offline" indicator while the "Online" indicator changes to "Go Online".
    – supercat
    Commented Feb 10, 2015 at 18:08
  • @supercat The status+action approach works perfectly in your situation too. "Online [Go offline]" simply changes to "Going offline [Cancel]" while disconnection is in progress, then to "Offline [Go online]". I think your suggestion of switching status and action around during disconnection would lead to confusion. Commented Feb 10, 2015 at 21:56
  • I think there should be a button which means "I want the system to be on-line" and one which means "I want the system to be off-line", possibly in addition to status text below them. The button which corresponds to either the system's current or "target" state should be disabled, but someone who wants the system to end up in a particular state should be able to have a clear course of action to get there.
    – supercat
    Commented Feb 10, 2015 at 22:18
  • @supercat It seems as if you'd prefer to do away with toggle buttons completely. This seems quite reasonable too. Commented Feb 11, 2015 at 1:57
  • 1
    Toggle buttons are fine for things which have exactly one bit of state and it can be controlled directly by the button. I consider them problematic for things which have state beyond what the button can directly control.
    – supercat
    Commented Feb 11, 2015 at 15:56

Discord is a VoIP and instant messaging social platform. In a UI update, the checkboxes in the settings were facelifted such that the current state and future state are unambiguous:




For the Play/Pause example, I'd show the current state normally and the opposite on mouse-over (when that's appropriate i.e not on touch screens). That item has 2 natural states and no unifying verb. On/Off on the other hand can be simplified to Power with the On state being lit and the off state, well, not.


I'd always go with current state. I think the play/pause idiom is the exception rather than the rule. I think play/pause being like it is, is possibly a holdover from the days of old cassette tapedecks. When play/pause were combined on CD players, I remember thinking how cool & innovative that was.

Anyway, one way to make it obvious that the current state is "selected" is to make the button glow a bit, or outline it with some magic looking blue.

enter image description here

Magic blue usually means some state is "on"

So, the above button is actually a tri-state button from iTunes. It has 3 states: repeat off, repeat all, and repeat 1. It's pretty clear what's happening here from the button's face. Repeat 1 is on.

As another example, I have 3 different cameras settings that are toggled by a single button: orthographic 1-up, orthographic 4-up, and perspective. A single button cycles through these 3 states, and I'm showing the current state on the face of the button.

Single buttons for multiple state are not that confusing once you get used to them. They are great because they group mutually exclusive settings, and they save cluttering the UI up with many distinct buttons. In a way, they are like a compact radio button.

Other options I could think of are:

  • Show current state, and pop out a menu to change state (even if there are only 2 options)

An example of this is how Mac os shows you the state of your BlueTooth or Airport -- it even has a popout with full sentences about what each action will do:

enter image description here

It shows its current state (faded gray means off), and it shows next states via a popup menu with full sentences.

  • 1
    I always preferred separate "play/pause". For video players, "pause" can then easily double as a "frame-step" function, and on players where the play button may not react instantly, the effect of pushing the play button when playback has been requested but not visibly started is ambiguous.
    – supercat
    Commented Feb 10, 2015 at 18:25

The label on the toggle button like Play/Pause should not change. The button itself should visually indicate that it is pressed (leaving the label 'Play'). This eliminates all the confusion.

  • I think your answer is very similar to what Rob Allen also proposes.
    – jpierson
    Commented Feb 7, 2011 at 17:35

The correct, unambiguous way to do toggles

This way it's very clear what the state is and what the state will be if the toggle is clicked.


@Kato's answer images from Evernote put it clear: there is the label communicating what is controlled by the toggle ("Auto save"), and the toggle, which doubles as a state indicator (O | I).
The problem with some toggles is trying to use the same bit for two different purposes: communicating the state, and communicating th action.
My home´s lights, for example, have an anonymous toggle and a bright indicaror, which is the light itself (when the bulb fails we usually can´t tell if the toggle is in the on or off position).
The play | pause arrangement also has a clear on indicator, the sound of the music itself. The toggle fulfills one function (control), the music fulfills the other one (communicate state).
The shffle vs. linear toggle controls the state, but doesn't communicate it. You would need to grab the CD case, wait for a theme to finish, and check if the one that starts after is the next in the list or not (and repeat to be sure). But if you think it as a shuffle | not-shuffle binary option, then you might label after the behaviour it controls ("shuffle" as a verb) and communicate the state by illuminating it.
As I see it, in any case you need to communicate the state.
A friend of mine is mad about his car's lock remote control. It has a state printed and he doesn't know if it's the action or the feedback.

  • The play/pause toggle concept only works in cases where the effects are instant and obvious. If the playback button doesn't always have immediate effect, then it's unclear what action should be expected if the user pushes the button and, having observed no response, pushes it again. In some such cases, the user might want to cancel or delay the upcoming playback, but in other cases the user might be wanting to ensure that the device will in fact commence playback as soon as it is able. With separate buttons, both cases can be handled easily. With one button, it's a mess.
    – supercat
    Commented Feb 10, 2015 at 18:28
  • @supercat: you are right, for the cases where the immediate behaviour doesn't provide immediate feedback. On the other hand, it is really nice to be able to alternate stop and play of a video without repositioning the mouse, like in youTube. Different cases would require adequate solutions.
    – Juan Lanus
    Commented Feb 15, 2015 at 14:46
  • There are times when toggle functionality is helpful, but also times when it's helpful to be able to perform a specific known action. I wonder how well it would work to have adjacent play and pause buttons, but when either is clicked have it turn into a double-wide toggle button which would remain in that state until the mouse went elsewhere?
    – supercat
    Commented Feb 15, 2015 at 17:21

To reduce ambiguity I suggest:

  1. Use the action as the text of the toggle button, not the state.

  2. Make sure the button isn't highlighted.

  3. Highlight the action on mouse over/focus to emphasize what will happen.

  4. Highlight the current state and place it next to the button.


enter image description here

(other examples: "turn on"+"off", "turn off"+"on")

Or you could use sliders and

  1. Highlight the current state, which should appear on the thumb control

  2. Place the action that transitions the state within the empty area (do not highlight it)


enter image description here

(Imagine the thumb control looks like a thumb control and not like a button)

Taken from my answer to the closed duplicate question with some improvements.

  • 1
    I like the idea, but the single letter difference means it takes ages (at least now when my eyes are tired). The colors are highlighting the current state but they also invite me to push them down. The gray area look like pushed... so much negative points from a newbie here, no offense meant!
    – maaartinus
    Commented May 18, 2014 at 5:07
  • @maaartinus None taken. Ideally the sliders should look more like grips than like buttons, however, I was too busy to draw them and just used PowerPoint for the sketch. Commented May 18, 2014 at 14:26

The following solution indicated in the answer by Daniel Alexiuc looks great to me: enter image description here

What is important is to see the current status. The action to change the status should be discoverable, but the indication does not need to be shown permanently.

Some form of slider could be more intuitive, but takes up more space and is not well suited for status indicators that function like buttons.


It should show the next state always, and to avoid confusion it should say "push to... NEXT STATE not just NEXT STATE. Why? because 99% of users go to seek the "switches" when they "NEED" to change something. Few users go to "see" the "switches" when they are happy with the current state of their app.

  • 1
    Letting the user know the actual state of the system shouldn't be a goal of the UI?
    – Stefano
    Commented May 27, 2017 at 9:20
  • But how do the users know the current state?
    – Alexey
    Commented May 1, 2022 at 10:11

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