Toggles-Yes, No or May Be.

7 min readJan 23, 2020

I will suggest to read this first just to set the context.

Let’s Design a Toggle

Let’s take a checkbox and design some something out of the box. I mean literally. The reference we have is the knob from the plane.

Now it’s time to add a holder the same way we had for door knob. We need to add an affordance to it so that the users will know where to click or tap to interact with the component.

Well, not bad. But smaller circle is still missing the something. Something that makes it feel like holding, grabbing or clicking. It a flat design as of now. What if it we make it 3D. Let’s add some z-index i.e shadow to it so make it feel as if it is floating within the grey rectangle.

That’s perfect. This is one state of a toggle now lets design the other state where the smaller circle is on the left side.

Great!!! Now we have two states of a toggle. But will the user be able to figure out which one is on and which one is off. Which one is enable and which one is disable. Let’s dive into various aspects of it:

Universal Language: So when the smaller circle is on the right it means on/active/enabled. Why because thats how we have seen things around us. For example, A Knob, when it’s on the right it enables the function of locking the door. The users are trained to turn things to right to turn it on. Our typing/writing is from left to right mostly, rating scale is left to right, 0–10 scale is also from designed in a way where 0 i.e unlikely is on the left and 10 most likely is on the right.

But there is a problem. These assumptions increases the cognitive load of the users as they have to think before interacting the toggle. Hence we cannot only depend on the alignment of the inner circle. We need to add more to our toggle to make it intuitive.

Color: Yes, let’s add colors. Green means go/activated/on and red means stop/deactivated/off. Thats pretty much a standard as our signal light are green and red. Anything that is danger is in red and anything that is in green is good to go.

But it fails. When it comes to a color blind user, this is how they see the toggle. Which brings us back to the previous point of depending on universal language and we know it’s not a good practice.

It also fails when it comes to branding.

SaaS/Branding: Imagine you work for a company which has clients like Walmart and Target. And you are given a task to design a toggle for one of them and with just one rule i.e you have to brand the toggle according to their branding guidelines. Now when you design it for Target then their active toggle will look something like this:

This mean blocked/deactivated/error/off. What does it mean? As we have seen before red is generally used for stoping or restricting but in this case it’s the opposite. That’s why relying purely on the color is not a good option. Also it leads us to another problem.

WCAG 2.0: It basically talks about why color should not be the only way to differentiate between two different controls.

Success Criterion 1.4.1 Use of Color (Level A): Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Now there are multiple ways we can solve this problem. One way to solve this problem is by doing the following:

Left normal view. Right Monochromacy/Achromatopsia view

Yes, this does solve the problem. We can clearly differentiate between two different toggles. One toggle is filled where as other toggle has an outline. But again we end up in same problem as discussed before of relying on a universal language to know which one is what.

Legend: One was to tell the users which toggle is on and which one is off is by adding a text near the toggle. The text will act a signifier for signifying the state of the toggle.

Does this solve the problem? Yes. Is it a clean solution? No. Imaging changing text for different languages. May be there is a language in which “Disable” is written in more than one words. In this case, the simplicity of the design will be compromised.

Icons: Sounds promising. There are many advantages of using an icon. Icon means the same in all the languages. Icons acts as a universal signifiers all over the internet. So let’s now design a toggle with an icon in it.

Adding the icon did solve most of our problems. Also by adding a little animation, we are giving an additional affordance on how to interact with a toggle. It passes the “Success Criterion 1.4.1 Use of Color”. As we are not only differentiating on the basis on color but also differentiating by the icon. The icon acts as a primary signifier to differentiate between two different states of a toggle. We have used an externally consistent icon for ON state i.e checkmark and no icon for off state. We are not using text as a primary signifier anymore. As it leads to the problem of how to display in different locals. And also adds complexity when it comes to responsiveness.

There is only one problem with this design. Let’s go back a little bit.

Remember we talked about getting an inspiration from everyday objects. So we looked at the knob example in the other post.

The lock symbol was outside the knob. The reason why it was outside was because when user was trying to interact with the control the icon was never covered. In this design we did the exact same mistake. We placed the icon in the inner circle. Now when the user hovers over the toggle to interact, the icon gets hidden behind the mouse pointer. That makes user think whether it is an on state or an off state. And we know rules of UX:

First rule of UX: Don’t make them think.
Second rule of UX: Don’t make them think.
Third rule of UX: Don’t make them think.

In this case, the best thing to do is to pull the icon from inner circle to outer rectangle. So that when the user interacts with the control then the icon never hides behind the cursor. Let’s design the toggle where the icon is in the outer circle.

Perfect!!! This may be the toggle which we are looking for in our designs. Quickly let’s go through the different checks:

Inclusive design. One control which works for all. No need to go in settings and interact with another toggle to enable accessibility. And end up creating another accessible control.
It has enough affordance for users to interact with the toggle.
It has icon to signify the current state of the toggle.
It also has the color to additionally give significance to its state.
Passes the WCAG 2.0.
If provided with the right alt attribute then it will work with screen readers as well.

Additionally, we can keep the legend to add another signifier to the state of the toggle. But IMHO, I will not recommend this approach as we started with a purpose of building a simple and intuitive custom web control not a frankenstein model.

Last but not the least

Every toggle needs a label to it. For example, input field in a form says “Full Name” somewhere within the proximity of the control. Similarly, toggle always has a label associated to it.

🔥 Pro Tip: Toggles needs to answer a question that has a binary answer.

The label associated to the toggle also need to be action oriented. It’s not necessarily to have action oriented labels but its a good to have action oriented copy.

Conclusion

A toggle with an icon in the other rectangle. And has the legend underneath with an action oriented label which has a binary answer to it. Is it an ideal toggle? No. That’s the beauty of design. There is no universal design that has one-size-fits-all solution. Because the designs are made for humans not for computers. Every designer will have different problem statement to solve. And different set of target users.

As far as designer understands the problem statement properly. And knows the target users. Then this article can act as an initial reference guide to consider various aspects of a toggle while designing one.

Toggles-Yes, No or May Be.

Let’s Design a Toggle

Last but not the least

Conclusion

Resources

Written by Tanmay Songade