It isn’t easy to figure out when to use a salad fork or dinner fork just by looking at them. This difficulty is caused by the fork’s similar form and function. Both have prongs for spearing food, but each is designed for a different food course.
Similar Functions but for Different Contexts
Forks confuse people in the same way that switches and checkboxes confuse designers. Many designers think it doesn’t matter when you use one or the other. But the arbitrary use of them can cause unexpectedness and confusion. Like forks, these user interface controls are for different contexts.
Switches and checkboxes are both used to enable settings. But the immediacy of when users expect those settings to activate are different.
Using these controls in the right context will make your user interface intuitive to use. But using them in the wrong context can cause users to wonder what went wrong.
Switches Are for Instantaneous Actions
Switches always indicate whether a setting is on or off. When users turn a switch to “on,” they expect an instantaneous action as soon as there’s a change in the visual cue. This cue change is what signifies “on,” not just for UI switches but real-world switches too.
When you flip a light switch on, you expect the bulb to light up in an instant. Any delayed effect or need for further action makes you think something is wrong.
Switches should never require users to press a button to apply the settings because a switch is a toggle button. When you require users to press a submit button, you confuse them because it’s not what they expect.
You should only use switches on settings that need to take effect instantaneously. If a setting requires a button press before it can take effect, you should use a checkbox instead.
Checkboxes Require a Button Press
A checkbox does not apply the settings at an instant like a switch. Instead, it’s has a submit button and takes effect after the user presses it. Requiring a button press allows users to review their settings before they commit. This requirement helps prevent accidental activation errors.
The visual cue of a checkbox is different than a switch. While “on” implies instance, a checkmark only indicates selection. This difference in signals means users expect a more immediate change with switches than checkboxes.
Checkboxes are useful for applying a batch of settings. With switches, users have to wait for the system to apply each setting one by one. Checkboxes allow the system to handle multiple setting changes at one time.
If the user changes a batch of settings often, checkboxes save more time. But if the user will change only a few settings often, switches work better.
Deciding Between Switch or Checkbox
When choosing between a switch or checkbox, focus on context, not function. Ask yourself whether a setting should take immediate effect or not. Ask yourself whether users need to check their settings before they apply them.
Many real-world objects have similar functions. But similarity doesn’t mean they’re a fit for any occasion. There are subtle differences that come into play for a specific context. These differences are details that designers should never ignore, or they’ll end up misusing the object.
Book
Affiliate
Excellent article,
Our programmer has used a switch in an application which requires saving button afterward. I just explained these principle differences between checkbox & switch to him and he was speechless 🙂
Never thought about it like that. Great article.
Great article. I have to bookmark this one for future reference 🙂
Been using switches and checkboxes for a long time without noticing this difference. Thanks for clarifying.
Nice article! I would like to see the same discussion on checkboxes and toggle buttons.
Our programmer has used a switch in an application which requires saving button afterward. I just explained these principle differences between checkbox & switch to him and he was speechless
Learned a new thing. Now time to implement them properly in themes. 🙂
Good article, but there is a key thing you have missed; the mental model of a switch vs a checkbox for the user.
A switch, as implied, has an on or off state. If turned ‘on’, it will remain on until turned off. Like a light switch in the real world and like settings such as WiFi or Push Notifications. On is on, until stated otherwise. If this is true for the interaction (always on) then great, if not…
Checkboxes offer a different state, in that a user is turning ‘on’ temporarily and it is not permanent. This is important for certain user behaviours/interactions such as agreeing to terms and conditions, but a submit action takes place. Next time the user returns this feature will not be ‘on’
What do you think about the vast number of product displays that use checkboxes for filtering by item categories?
Absolutely disagree. There’s no fundamental difference between a checkbox and a toggle switch. Additionally, toggle switches are a smartphone thing thing that don’t exist in many UI toolkits which use check boxes for this purpose.
Additionally, if you think an end user is basing whether a setting will apply immediately or not based on the use of a button/checkbox or otherwise some other customer chrome for a toggle setting you’re mistaken. Developing apps in 2019 is difficult because different platforms have different conventions but many applications and all websites work across all platforms. This means that any given web-site or app you use might be using conventions from somewhere else.
I can go into MacOS “System Preferences” and see many instances of checkboxes and these settings are applied immediately. Same thing for Firefox, Slack, BBedit, Thunderbird settings.. In fact, the only app I can find that uses switches is Chrome which makes Chrome the inconsistent one. The platform convention on the MacOS is to have all preference panels apply settings immediately and there’s not such thing as a toggle switch. On windows there’s about a 50/50 chance of applying settings immediately and again toggle switches are extremely rare. As an end-user when I see a checkbox or toggle switch I make no assumptions.
I’ll buy that toggle switches should be used for settings that apply immediately but only because *all settings should apply immediately*. Not applying settings immediately is *primarily* a legacy thing because in the olden dayes computers didn’t have the power to apply settings immediately.
If you want to improve your UIs you should always strive to have settings take effect immediately.
One’s UI must make clear if a page of settings is of a “save” type because this type is now a rare exception. Make the manual save/apply nature of your settings page/dialog *very* clear by having the button clearly visible on all screens.
@ Andrew Trumper — Your argument is that because checkboxes/switches were used wrongly, therefore it doesn’t matter. That seems a bit dysfunctional. I agree with the article.
Your article proposes a rather well-considered convention which can help designers choose form components in many simple cases. However, I feel it is an oversimplification in many real-world situations.
Often these days, particularly with filters and configurators, SUBMIT (as well as RESET) buttons appear alongside select/switch choices that are applied immediately. These SUBMIT buttons may seem obsolete, but they provide a fallback which can be a good thing for UX and accessibility.
It is true a toggle switch is ideal for device or product settings, where changes are applied immediately and affect some modal feature. However, with more transient or taxonomically grouped selections, then I feel a checkbox is still a good convention, whether the changes are applied immediately or not.
@Robert, A toggle button is a switch. It says it in the 7th paragraph.
Good article. It agrees with well known UX standards:
https://docs.microsoft.com/en-us/windows/apps/design/controls/checkbox
https://developer.apple.com/design/human-interface-guidelines/macos/buttons/switches/