A toggle is a switch that has two positions—on and off. It’s also used as a verb, as in “I toggled between the three cameras at the museum to capture different perspectives.” This simple user-interface component is used to allow users to quickly update their preferences or settings and deliver immediate results. When toggles are designed well, they provide direct labels and standard visual design so that users can interact with them without any confusion.
A toggle can be either a default or small toggle. Default toggles are larger in size and typically appear within forms or full pages of information. They are required to display a toggle label and action text, while small toggles are more compact in size and appear inline with other components or content. Both toggles are required to have the following interactive states:
In addition to on and off, toggles can also be in one of four active or passive states: focus, disabled, read-only, or skeleton. When inactive, a toggle is not visibly present on the screen or is dimmed and unclickable. The read-only state is similar to disabled but allows the toggle to be clickable and provides a visible indicator that the toggle is displaying only static content.
The skeleton state is the least interactive of the toggle states. When the toggle is in this state, it is not clickable, does not change its current displayed value, and does not pass WCAG contrast requirements. A skeleton toggle should only be used when it is not possible to use a disabled or read-only state for a specific reason.
Toggles are often used to perform multivariate or A/B testing on a given piece of functionality. When enabled, an experiment toggle will consistently send a cohort of users down one codepath or the other so that you can analyze which path works better for them. This is commonly used to make data-driven optimizations like changing the call-to-action wording on a button, or adjusting the default purchase flow for an ecommerce system.
Savvy teams consider their feature toggle inventory as a type of carrying cost and seek to keep it low. They may add a toggle removal task to their backlog whenever a new release introduces a toggle and other teams go as far as adding “expiration dates” to their toggles so that they are automatically removed after a set period of time.
Despite the benefits of using feature toggles it’s important to remember that they are a temporary solution and should not be in place for more than a few weeks (although product-centric toggles can stay in place for longer). They also have a high maintenance cost, which can be exacerbated if they’re accidentally left in place by newer members of the team or by a rogue engineer who forgets to remove them from their own codebase. To avoid this issue some teams adopt a policy of always adding a toggle removal task to their backlog when a new release first introduces a toggle.
