Toggle is an HTML element that provides a convenient user interface for changing settings and configuration options. Unlike checkboxes or radio buttons which rely on visual cues to indicate a state (active or passive) toggle switches enforce a mutually exclusive state and provide an immediate result when the user presses it.
Toggles are frequently used for settings and configuration options that require a user to change between two opposing states. To make these toggles as easy to comprehend as possible designers often use direct labels and standard visual design. However, this approach comes with significant cognitive costs and in some cases can cause confusion for users who may be unsure what the current state of the toggle is.
In this example we see an UI with a toggle that has three labels describing what the switch will do (no cookies, no ads, and no tracking). Unfortunately, the leftmost label is obscured by the toggle button. This leads to an experience that doesn’t match expectations and can lead to users unnecessarily switching the toggle off and on.
Fortunately, there are solutions to this problem. Toggle UIs can be made more usable by using more subtle visual cues that convey the current state of the switch. For example, we can use a darker color for the active toggle button and a lighter color for the inactive toggle button. In our research we tested a couple of different combinations of these visual cues and found that using a darker color performed better than a lighter color.
Another way to improve the usability of a toggle is to change the text that is displayed next to it. We tested a few different variations of this, and found that using more descriptive text helped to mitigate some of the cognitive costs associated with toggles. The most clear text was a bolder font than the standard sans-serif, but even this didn’t completely fix the issue.
The last common usability issue with toggles is that they can be difficult to understand if the toggle is not in its default state. In some cases this is because the toggle is ambiguously worded (as in this example) but in other cases it can be because the toggle is used in the wrong context. For example, when a toggle is used to download content it’s important for the toggle to be clearly worded to explain that turning the toggle on enables downloading while turning it off prevents downloading.
In addition to ensuring that toggles are correctly configured it’s important for teams to test the expected behavior of their toggles. For this reason many teams use feature flags as they build out their products so that it is possible to easily change the default toggle configuration from release to release. This can be as simple as commenting the toggles in source code or using a preprocessor’s #ifdef functionality where available. For more dynamically re-configurable toggles it’s sometimes necessary to use a separate tool such as code or behavior togglers which can be triggered to run at certain times in the build process or when new features are enabled/disabled.
