A toggle is a control that allows people to set the state of something. Toggles are used to manage things like the visibility of a component, the state of an ajax call, or the activeness of a call-to-action button. Toggles are designed to be mutually exclusive, requiring users to make a clear choice between two opposing states. This makes them a great way to implement multivariate testing or A/B experiments. In addition to their flexibility, toggles are easily accessible by assistive technologies like screen readers and keyboard access.

The primary use for a toggle is to make it possible for people to switch between settings or modes in an application. This is often done in a form of a dropdown menu or a checkbox. Depending on the context, a toggle can be either an active or passive control. Often, a toggle will be labeled with an icon or text to help distinguish its state. Toggle icons are usually circular, indicating that the current state is On. Toggle labels are often written in a bold font and often placed to the right of an icon. This is in line with the proximity principle, which states that a user can intuitively determine what an icon means by how close it is to its associated text.

Toggle configuration can live side-by-side in source code files. This makes it easy for product managers, QA and other teams to change toggle configuration. However, at a certain scale this approach can become cumbersome to manage. For this reason many organizations move toggle configuration into some type of centralized store, often an existing application DB. This is typically accompanied by the build-out of some form of admin UI which allows system operators, testers and product managers to view and modify the toggles they are managing.

It is important to keep the inventory of feature toggles small and minimize the number of toggles that overlap with each other. This can prevent confusion for users and reduce the complexity of debugging. It is also best practice to give each toggle a meaningful name that helps someone quickly understand what it does. This gives a little extra information that could be helpful if the toggle is accidentally called in error, as well as helping a team track the state of a particular toggle over time.

Finally, it is important to test all of the toggle configurations which are intended for release. This includes the live production toggle configuration plus any toggles that are being rolled out with a fallback state of On. This can help avoid surprise regressions in a future release. This is why many teams add a specific test to the QA pipeline to run against any new releases which contain feature toggles. A common name for this is the “test that all features have a toggle On”. This is not a substitute for thorough testing of all production releases, but is an extra precaution against unexpected behavior in the event that a team forgets to test a new feature toggle.