Do variants spark joy?

Figma goes Marie Kondo

Figma introduced variants promising us, designers, a new and delightful experience. I quickly set out to check just how delightful are we talking about.

But what are variants? They are not only a method for organizing components within a design system but also a tool for forging a better understanding between frontend engineers and designers.

Before variants, our design system at Homeday was a web of instances, forward slashes, and manual labor. It did not spark joy. In this article, I’ll go over the creation of a variant group and how to use it efficiently to organize your design system and speak to your engineers.

Here to talk about your Lord and Savior, the Design System.

How do engineers think of variants?

For an engineer, a component has props and controls that define how it’s displayed. Type, size, or color can all be props. In short, we have a number of dropdowns and toggles to adjust the component.

Here’s an example of the props of a button.

You can view the button props in Homeday Design System (public)

Variants are organized very similarly, they let you toggle or switch between similar versions of a component. But what’s even more useful they let you create slight variations without recreating or copying components.

In a nutshell, variable components are more interactive and allow designers to think more in an action-reaction mode rather than in still images. We all know that design that works until you touch it.

No touchy! The design is sleeping.

The anatomy of a variant

Probably the most obvious example of the use of a variant is the button component. Let’s assume that our button:

• is either primary or secondary
• has different states
• may feature an icon

Note that this description is already helping us define the properties. Let’s create a very funky button:

1. Create your basic button and turn it into a main component. Variants and design system components work great with auto-layout, which I wrote about in Embracing Constraints. You’re welcome to start with the most basic or the most complex version of the button, the variation group gives you a lot of flexibility for editing.

1. Create another main component. Select both and choose “Combine as variants”.

1. Adjust your properties. This is the tricky bit depending on how complex your components are and what variants will be the most important for your design system and prototyping. As a rule of thumb, less is more.
   Technically, you can create either dropdown with properties or a toggle. If you’re still not sure, ask your engineer for a list of props. Actually, scratch that, if you haven’t discussed a component with your engineer, you’re doing something wrong.

As you can see in the example above, creating a toggle requires a property with values of either yes/no or true/false.

You can adjust the stroke and fill of your variation group, just as if it was a regular group. Sometimes adding a background to your components can help you navigate the asset search easier or catalog tokens, atoms, and molecules within your UI pattern library in Figma.

When (not) to use variants?

Of course, the primary use of the variants is for the organization of the design system but it can be a powerful prototyping help, especially for realistic user tests before development.

Variants work for components that have strong ties but have different states or colors, elements that either turn off or on. They are not a good fit for components that are very distinct, for example, a set of icons. Another pitfall could be creating variations of components that do not have all the properties in common, for example, radio buttons and checkboxes. It could be tempting to create a variation on the theme of “selection controls” but radio buttons do not have an indeterminate state, which throws off the whole organization.

A similar function does not always mean that the components exist in the same variant group.

Similar function but different variants

When creating variants of a very complex component, we should carefully consider the props (properties in Figma). I would first list the most common differences (mobile or desktop, status change), before considering cosmetic variations (color, theme). If possible, we should always keep the component simple. Creating slight adjustments might be tempting but creates a mess. And don’t forget, if you need to adjust the color of the component or the typography, you can always do it on the instance level.

Nesting instances

Chances are, your design system will have a number of components that are exchangeable. For instance, icons are most likely going to be a part of a number of different molecules or organisms. This is why the best way to avoid a complete mess is to create Matryoshka doll components.

Here’s an example.

Summing up

The one risk of variants is creating more complexity than necessary, so organize responsibly. Chances are your designs will never even touch some of the variants you created, but the greatest value of the design system is clear documentation and that’s what variants are here for. Best of luck experimenting!

Feel free to check out my other articles about Figma and design:

• Embracing Constraints (about constraints and auto-layout)
• Honey, I shrunk the UI Illustrations (about building a second set of icons in a smaller size)
• Minimalism in UI illustrations (about simplifying meaning for an icon set)
• No-Bullshit Illustrations (about branding principles in building an icon set)
• 404: We have a problem (about 404 pages)