Toggle Buttons
Somebody opens a settings screen to stop the email notifications. They find the row, look at the little control beside it, and cannot tell whether it is currently on.
One small switch, many wrong designs. Learn the right one before your next stop.
Listen to the full Toggle Buttons course on DesignPath
They tap it, watch it move, and are now equally unsure. So they leave the screen, wait for the next email to arrive, and come back to try the other position.
That is a control with two states and one job, and it lost. Eduard Kuric tested 27 toggle designs with over 100 people for UXtweak. The most common treatment in the wild, red for off and green for on, produced a 32.5% error rate. A third of people could not reliably say which state they were looking at.
A switch is small enough that nobody reviews it and common enough that everybody ships one. Getting it right is a handful of specific decisions, and the first of them is whether the control should be a switch at all.
Anatomy of a Switch
A switch is a small component with more parts than its size suggests, and the argument in a review is usually about a part nobody has named.
The Five Parts
Two are the control and three are around it.
The track, the rounded shape holding the whole thing. The thumb, the circle that moves across it. The label, naming the setting. An optional state text, the word beside it saying on or off. And the row, meaning the full width strip the label and switch sit in, which is the thing a finger actually aims at.
The row is the part most often left out of a design file, and article 4 covers why it matters more than the switch's own size.
Four States
Three of the four are usually drawn.
On and off, which is the whole point. Disabled, for a setting this person cannot change, which Hidden vs Disabled covers as a subject of its own. And pending, for the moment between the flip and the server confirming it. That fourth state decides whether the control can be trusted. A switch flipped but not yet saved looks identical to one that has been, and article 7 covers what to show there.
Where It Sits Among Its Neighbors
Three controls do overlapping jobs and are not interchangeable.
A switch turns something on or off and applies immediately. A checkbox records a choice that takes effect when a form is submitted. A segmented control picks one of several named options rather than two. Article 3 runs the choice between them properly, and the shorthand is that a switch is a promise the change has already happened.
What the Shape Promises
The visual borrows from a physical switch on a wall, and that borrowing carries an expectation.
Somebody who flips it expects the thing to be done, with no save button and no confirmation. Every later rule follows from that promise. The label names a state rather than an action, the change is visible without color, and something happens when the server refuses.
Pro tip: Count the states in your design system's switch component. Three means the pending state was never drawn, and the behavior on a slow connection was decided by whoever built it.