When to use toggle switches? A reusable design pattern

Over a short period of two years, the UX department at Yoast has grown from one UX designer to the current UX team of four designers. In the early days, we were used to making UX decisions based on gut feeling and common sense. At times, these designs worked out well, but sometimes it turned out that they could have been better thought out and/or could have been applied more consistently amongst our products. Therefore, we started to develop (and are still developing) a design system with components and patterns based on more conscious and informed decisions. As a part of this process, we’re trying to discover reusable design patterns:

“A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem. It describes the problem, the solution, when to apply the solution, and its consequences. The solution is customized and implemented to solve the problem in a particular context.”

Gamma et al. (1995)

In my opinion, establishing design patterns is an essential step towards achieving design consistency in our products. Furthermore, it will lead to better thought-out designs and will most likely save us time in the future. If a reusable pattern is available, we don’t have to spend time reinventing the wheel, so to speak.

At Yoast, we are currently in the middle of establishing such a reusable pattern for the way we present choices to our users. To achieve this, I decided to go through a process that I like to divide into four phases: Analysis, Research, Review, and Documentation. In this article, I will take you through these phases and describe my approach.

Analysis: discovering inconsistencies and establishing new pattern opportunities

When first looking at our products, I immediately noticed that we offer our users a lot of different types of choices. Choices that can be made by interacting with some well-known web-native input controls like radio buttons, checkboxes, and dropdowns.

I quickly discovered is that we didn’t always use these selection controls consistently amongst our products. I found a lot of comparable situations where we used different selection controls. Moreover, besides using web-native selection controls for presenting choices, we’re also using toggle switches quite a lot in our products.

This challenged me to really get a grasp on the concept of a ‘choice’; to analyze and define what this concept means to us and our users. By zooming out on the problem, I was able to identify a few different choice styles and was able to define each of these controls as a choice component.

For me, a choice component is an element that offers the user the possibility to choose between:

• Two options in the form of a binary choice (e.g., ‘on’ and ‘off’)
• Two options in the form of an opposing choice (e.g., ‘annually billing’ versus ‘monthly billing’)
• A list with multiple options

The next challenge for me was to determine which selection control is best suited for each of those situations. Is it a single checkbox, a group of two radio buttons, a toggle switch, a button group, a dropdown or a list of radio buttons?

To be honest, this challenge quickly felt too extensive to be able to solve simultaneously. This is why I decided to look at it from a different angle, namely that of the selection control itself. For each selection control, I asked myself: “In which situation or use case is this control a logical and intuitive fit?” To be able to answer this question, I decided to do some research. And this brings me to phase two of my process.

Research: involving theoretical principles

My research started with the use of the toggle switch. And to keep a clear scope, this is what I will focus on in this blog post.

During my analysis in phase one, I created an overview of all the places where we are using toggle switches in our products, simply by making screenshots. Again, this analysis taught me that there were no clear patterns to be discovered in the way we use the toggle switch. Therefore, I decided to do research on the subject.

After searching for a while, I found an interesting article written by Alita Joyce of the Nielsen Norman Group, a user experience consulting firm that published many research-based articles about UX principles.

The article by Alita Joyce clearly states that we should strive to match the system to the real world. For example, one of the main messages from this article is that a toggle switch is a digital variant of the analog on/off switch and therefore should provide immediate results (like when you switch on the light or switch on a coffee machine):

“Toggle switches should take immediate effect and should not require the user to click Save or Submit to apply the new state. As always, we should strive to match the system to the real world.”

Alita Joyce (2018)

The article mainly focuses on the conceptual use of a toggle switch, but it doesn’t really give examples of what practical cases ask for the use of a toggle switch. This led me to another article that went deeper into specific cases about its usage by describing the so-called ‘do’s’ and don’ts’.

Having studied both articles, I was able to establish a clear set of principles on how and when to use a toggle switch:

• A toggle switch represents a system state, not a contextual one
• A toggle switch represents binary options, not opposing options
• A toggle switch is used to activate a state, not to perform an action
• The effect of a toggle switch action is instantaneous (it doesn’t require a save or submit action)

These principles feel like a solid basis for the use of the toggle switch. But at this stage, they’re still only that: principles. An important step that still remains is to test if these principles hold up when I apply them in our products. This brings me to the third step in my process.

Review: turning the theory into practice

The theoretical principles from existing research are very useful, but it’s always wise to check whether these principles also work in practice. This depends heavily on the context in which these principles will be applied. Also, we’re already using toggle switches in a lot of places across our products. Therefore, I want to test and review whether we’re using the toggle switch correctly according to the theoretical principles from the research phase. But also whether our products require for me to alter those principals. Whether they actually work in practice.

In this blog post, I want to walk you through this review phase by showing you some concrete examples from our products. Currently, in Yoast products, toggle switches are used in:

• Yoast SEO for WordPress: General settings (on/off) and Search Appearance settings (yes/no, show/hide, enable/disable)
• MyYoast: Subscriptions page (on/off)
• Yoast.com: Plugin or training subscription (billing monthly/annually)

Yoast SEO for WordPress

Looking at these situations, the toggle switches are not always used correctly according to the theoretical principles. In the settings of Yoast SEO for WordPress, toggle switches seem to be the right choice following the theory. Namely, they represent a system state with binary options (on/off), and they are used to activate a state. However, the theoretical principles also state that the effect of a toggle switch should be instantaneous. But in a WordPress context, using a ‘Save changes’ button at the bottom of the page is a common pattern. Therefore, to avoid confusion for the WordPress user, I decided to still keep the ‘Save changes’ button on this page.

MyYoast

In MyYoast, the usage of the toggle switch exactly matches the theoretical principles. In this situation, switching the toggle also takes immediate effect.

Yoast.com

On yoast.com, a toggle switch is currently used to switch between billing monthly and annually.

In this case, the toggle switch represents a contextual state with opposing options, which does not match the theoretical principles for the usage of toggle switches at all. On the one hand, toggle switches are often used for choosing between billing monthly and annually on other websites, but on the other hand, this does not follow the theoretical principles. We have to think about possible alternatives for this situation. The principles from the article of UX movement state that in this case probably toggle buttons should be used, but we’re not using toggle buttons in our design system yet. We also have to investigate if we really need toggle buttons or if we – for example – can also use radio buttons in this case. 

In summary, we want to follow the theoretical principles from the research phase as much as possible. However, in WordPress context – even when using toggle switches – I’m hesitant about leaving out the Save changes button at the bottom of the page. Also, we have to think about alternatives for the monthly or annually toggle switch, because the usage of this toggle switch is currently not following the theoretical principles. As you can see, doing research and reviewing the principles stemming from research can lead to additional questions that require additional research. And sometimes it requires you to be flexible in the way you apply these principles. 

Documentation: describing the use cases

Finally, after we’ve established the rules for using toggle switches in our products (and having established possible exceptions for its usage), these rules have to be documented properly. Clear documentation of these rules ensures that they can easily be interpreted and used consistently in the future. Currently, we’re still in the middle of creating a format for writing documentation. But I think it’s crucial that the documentation – at least – contains a clear description of use cases in which a switch should be used. Sometimes, it may also be useful to document edge cases and/or situations in which a switch should not be used at all.

Conclusion

After writing the documentation, I completed the process of establishing a reusable pattern for the way we use toggle switches in our products. During this process, I learned that doing research and reviewing theoretical principles in practice can lead to additional questions that require further research. In some practical cases, it turned out that I had to be flexible in the way I applied the theoretical principles. Eventually, this pattern contributes to achieving consistency in design and saves us time in the future. Defining a design pattern following this process, also challenged me to better think through my designs. It enabled me to make conscious and informed decisions.

It is probably due to my academic background that I really enjoyed going through this process and involving research-based theoretical principles. However, this doesn’t mean that I believe research-based design is always better than designs based on gut feeling. I firmly believe that a mix of a scientific approach (science) and a creative approach (art) go hand in hand really well. And I think every design team benefits from having those skills on board.

In conclusion, I’m really satisfied with this structured way of discovering and establishing design patterns, and I’m looking forward to using this approach in the future!