A toggle is a switch that has two positions: on or off. In the context of software this refers to an on/off control like a keyboard’s Caps Lock or Num Lock key. In the context of user experience, toggles can be used to allow visitors to update preferences and settings. When designing a toggle it is important to clearly communicate the state of the control and make it easy for users to change the state. This is done by providing direct labels, utilizing visual cues (i.e. movement and color) and using standard interface components.
A common use of Toggles is within an experiment to perform multivariate or A/B testing. By creating a Toggle that enables a codepath to run for a subset of the overall user population, it is possible to measure the impact of new functionality without interrupting the experience of everyone else. This allows teams to test different feature combinations in parallel with each other and choose the best one based upon actual data.
Another common use of Toggles is to control access to features for certain cohorts. For example, a team may want to limit the availability of a feature to Premium users. Toggle controls can be created that restrict access to the feature and easily changed at any time to reflect this decision. This kind of toggling is very similar to a Canary Release and can be used at the same scale.
While the idea of Toggles is very powerful it is important to be aware of their limitations. For example, if your feature flag system doesn’t support dynamic in-memory re-configuration of specific toggles it can be hard to exercise a toggle configuration. This can lead to issues around cycle times and impact the all important feedback loop provided by CI/CD.
A wise approach to managing the use of Toggles is to ensure that they are only in place for as long as necessary. A savvy team will treat their Toggle inventory as an asset that comes with a carrying cost and seek to keep it low. Some teams even add a task to remove a Toggle from the backlog when it is first introduced and some even create “expiration dates” for their toggles that will cause tests to fail if the feature is still in place past that date. These are all great ways to reduce the carrying cost of a Toggle.
