5 Common Design Mistakes & Myths About Checkboxes & Toggle Switches

Checkboxes & Toggle Switches

Last updated - February 24, 2020

User Interface (UI) & User Experience (UX) play key roles in the success of any mobile and web applications. Excellent UI and UX mean your products are intuitive, user-friendly, and easy to use. They improve your overall user experience and customer satisfaction, and so, create a long-lasting first impression. This leads to higher conversions and more sales.

Creating an effective UX and UI design requires many components, from visual and interaction design to usability. Among these elements, option selections including checkboxes and toggle switches are crucial factors in most software and apps settings. They control the display and how users input data. Not everyone knows how to use option selections correctly and flexibly though.

In this article, we’re going to discuss the top 5 common design mistakes & myths about checkboxes and toggle switches as well as how popular plugins handle these UI & UX challenges.

Without any further ado, let’s get started.

#1 Display all available options

#2 Use checkboxes to show & hide setting options

#3 Use Switches for Instant Response

#4 Checkboxes require a “Save” button

#5 Use the same UI for action and state

#1 Display all available options 

Have you ever used a contact form that includes everything for everyone and wind up spending so much time just to reach out to the right person?

Have you ever seen a settings page that lists all available options and found it too troublesome to make just a small change?

Displaying all available options at one go not only lengthens the form and settings page but also requires unnecessarily complex validations. On top of that, it confuses users with irrelevant options as well. For example, when looking for pre-sale questions, users shouldn’t be asked for “order number” and “license key”. On the other hand, when asking for support, users must fill in these fields.

Let’s take Password Protect WordPress plugin as an example. The plugin allows users to set a single password to protect multiple WordPress pages and posts at the same time.

Let’s say users have already selected “Hello” and “WordPress” pages and set a password for those pages. Now, they want to remove “WordPress” from the list of protected pages while still keeping the same password.

The natural tendency is to display all available options. So the “new password” field is there although users might not want to change it.

Here’s what’s going to happen:

  • First, you have to re-validate the password field that allows empty values, which means the password is not changed.
  • Second and most importantly, that password field confuses users more often than not. They wouldn’t know what the next step is. Re-enter the password or leave it empty? Does leaving the password field empty mean my pages are not protected anymore?
  • Worst still, if the password is encrypted, you can’t even show the current password, which causes even more confusion.

Creating different tabs for each section or various forms for certain types of customers could be a solution but not a perfect one. This usually requires complex setup and maintenance while sometimes degrading user experience. They have to look for different forms in different pages.

Ideally, a website shouldn’t have multiple forms and tabs for each user action. Instead, there should be only one form with certain conditional logic that dynamically changes the settings options or form fields on the fly, as the user selects or fills them out.

In other words, a better solution would be to group the same options into a section and easy-to-follow flow whenever possible. 

There are a few ways to do so. And here comes the second myth.

#2 Use checkboxes to show & hide setting options

It’s common to use checkboxes or select dropdowns to control the form logic and flow. There is a tendency to do the same for setting options.


In reality, when showing or hiding additional functions for setting options, it’s much more natural to use toggle switches vs checkboxes. This is a useful but less common usage of switches, apart from switching a single option on or off, on mobile and tablet.

There are a few reasons that switches are preferred than checkboxes when it comes to settings options. 

  • The option can be turned on or off. Users will need to turn on this option to select and protect their private pages. If they turn it OFF, these pages won’t be protected with the password anymore. So in this case, the switch is not only a toggle of sub-options but also a settings option on its own.
  • There are a lot of sub-options. While checkboxes are usually used on forms to show one or two extra fields, switches could be used to toggle a new settings section as in this case.

#3 Use Switches for Instant Response

Common sense: In the UI world, people usually associate a toggle with a light switch to turn things on and off with immediate effect. As a result, it usually doesn’t require a “Save” or “Submit” button.

In actual fact, we realize toggle switches and “Save” button can still go hand in hand in many cases such as showing or hiding sub-options.

Let’s go back to the example of Password Protect WordPress plugin. If users turn on the protection option, but don’t select any pages or key in a password, what should we do?

The traditional knowledge tells us to turn the protection option back OFF automatically after a while – say 10s if users don’t choose any pages.

When a user toggles a switch, its corresponding action takes effect immediately. If a switch cannot be turned on, the switch will automatically turn back off – material.io

The main drawback is switching off the option automatically albeit cool probably goes against users’ wishes.

Would it be a better user experience if there is some notification informing users what they did wrong or missed out; what they need to do next – instead of automatically turn things off? Users will then have a chance to correct it. 

Another solution is to validate the inputs on the fly. If it’s valid, save the changes. Otherwise, show users the validation errors.

This is also cool but not preferred technically as the plugin must make a server request every time users make or drop a selection. Let’s say, users are to choose 10 pages, 10 separate requests will be made. This apparently wastes unnecessary server resources.

It’s best if there is an event that triggers the validation process instead. That’s when the “Save” button comes in handy.

There are other cases when it’s necessary to reload the page to apply changes. For instance, when a new password is saved successfully, the password field is hidden by default (a significant UI change). In these cases, the “Save” button is a must. 

Likewise, it’s interesting that Asana is using toggle switches but not checkboxes for their user profile settings. Apart from the above reason, these settings options are independent items and not closely related to one another. These things also matter when choosing between checkboxes and toggle switches.

#4 Checkboxes require a “Save” button

Common sense: Unlike a toggle switch which involves both selection and execution, checkbox only shows an option selection. Its execution needs another trigger more often than not.

It makes sense, right?

Yes and no. In many cases, it does. But similar to switches, there are exceptions to checkboxes as well.

Checkboxes are used for instant responses too. Take a look at most live filters from Agoda to Booking.com. They’re all using checkboxes – not toggle switches for the filter categories. Similarly, WordPress is using checkboxes to show and hide page columns instantly.

You may wonder why they all go against “common practices”? Why don’t they use switches to immediately activate or deactivate something instead?

Actually, checkboxes make more sense in this case as there are various related options which just don’t look right with switches. What’s more, they take up much less space compared to switches as well.

#5 Use the same UI for action and state 

Combining status and action into one button used to be a common usage, especially on mobile where the amount of available space is limited. Twitter did this with their “Following” and “Follow” status. So did Instagram.

Prevent Direct Access plugin was using it too. Although it looks cool and saves some space, there are a few issues with this combination.

First of all, most users wouldn’t know if the “button” is clickable. To make it easier to understand, they then added a mouseover effect for the button so that it would turn red and the text flip to “Unprotect”. If users click on it, the file will become unprotected and vice versa.

Apparently, the button text and file protection state changing in a matter of seconds actually made users confused. They would be rather reluctant to click on a button whose text flip on mouseover. As often as not, this effect results in accidental clicks at best.

The solution is to always separate the state and action on Desktop where there is usually enough space to avoid any potential confusion for users. On mobile, it’s best to show a pop-up to confirm if users want to proceed with the action. This helps avoid accidental clicks and reduce confusion caused by continuous changing state.

Wrapping up

When it comes to checkboxes and switches, design matters and you should take a more flexible approach when choosing between the two. Checkboxes taking up less space are best suitable for related options while toggle switches make it clearer and easier to turn settings options on or off on mobile and tablet. It’s alright to use checkboxes for instant actions especially when the options are related to one another. Similarly, it’s fine to use switches for parent-child relationships especially when child options are hidden.

In short, here are 3 big things that we’ve discussed in this article:

  • Group similar options into a section; only display relevant options and fields to each group of users
  • Use checkboxes for related options and toggle switches for turning settings options on or off on mobile and tablet
  • Separate actions and states whenever possible


Please enter your comment!
Please enter your name here