Baseline #6 — Naming Variants

...and how to keep properties and values simple.

Apr 12

Hello again! 👋 I'm excited to be writing again after a bit of time away to recharge and adjust to a few new life changes. This newsletter will be a little shorter than previous ones, but maybe that's a good thing? Let me know! I love writing these, and your support always means so much to me. In this newsletter, I'd like to share how I typically name Variants in Figma and the approach I try to take whenever I'm feeling… stuck.

Figma Focus: Naming Variants

About Variants

If you're unfamiliar with Variants, they're essentially a way to turn several components related to one another into a single component with selectable options. For example, in most design systems, there are buttons, and each Button component may have a different state that can be used, such as default or hover. Before Variants, those states would have to exist as two entirely separate components, which, as you might imagine, quickly led to a very cluttered Assets Panel. With Variants, each of those states, along with any other adjustable properties, can all be part of a single component that's user-adjustable.

When creating Variants for a component library in Figma, two attributes can be edited and customized: properties and values. Properties are the controllable variables for the component, while values are the options available within each property variable, and there can be an unlimited number of each. Back to the Button component, a typical property name might be State, and its values could be either Default, Hover, Focus, etc. The Button component may have different states, but it could also have other appearances or sizes to choose from, too.

Challenges with Naming

When I was just getting started with Variants and updating components to use them, I had trouble knowing when to create a new property versus when to add a new value. I'd often end up with a component that had one or two properties with dozens of values each, and it didn't take long for components to feel way too complex and overwhelming to use, which led me to wonder why should I use Variants at all?

To illustrate what was happening, imagine a Button component that displays an icon either at the start of the label, the end of the label, or both at the start and the end of the label. My intuition told me to create a property called Type and add values that mapped to what the component was able to display. In doing that, there would be at least four different types: default, startIcon, endIcon, and... both? The problem with this technique is that the list of values under the property Type quickly adds up, and for cases where a component could display all, one, the other one, or both, naming wasn't easy. While trying to keep the component close to how it was referenced in the codebase, knowing what to name the Variant felt challenging and often impossible.

Taking a Different Approach

No naming system is ever perfect, but after a healthy amount of adjusting components and experimenting with different ways to create Variants, what began to click for me is the idea of creating a property for every adjustable item that I'm able to identify within the component. In the above Button example, instead of creating a property called Type and then adding several values to that property, I would now suggest creating property names startIcon and endIcon, containing either true or false values. This approach can help make knowing what to make a property and what to make a value easier and shows which elements are customizable and available to designers using the component library.

Tip: Using the values true/false, on/off, or yes/no in Figma will generate a visual switch, making the Variant interface easier (and more fun!) to use.

With this method, there's no longer a need to create two values that frequently share many of the same adjustments under the same Variant property, as those can now be broken into their values and set appropriately. In my experience, this approach has also helped me better align components to what's in code, as many of the property names can match the available props in code or that could one day be in code for the component.

I'd love to know your approach to naming Variants in Figma and keeping them organized! Does the above resonate with you, or have you found another practice that makes more sense for you and your team?

In case you missed it...

A few weeks ago, I published another update to my iOS 15 UI kit for Figma, which includes a few new things to help you create and design for iOS! Buttons, Alpine Green and Green iPhone wallpapers, center alerts, SharePlay options, Home Screens, and a new changelog have been added. If this project has ever been valuable to you or your team, having your support would mean so much to me!

Recent bookmarks

If you can't already tell, I frequently change wallpapers, and this week, I'm using a gorgeous Sierra Blue dynamic wallpaper from @basicappleguy.
Speaking of wallpapers, @rafahari recently shared a 6K version of the new wallpaper that Apple created for the Studio Display.
If you're using the new M1 iMac, you may know that macOS's accent color can be adjusted to match the hardware color, but those color options haven't been available to other Macs. Well, good news! This blog post explains how you can enable those hidden accent colors and use them on any Mac running macOS Monterey.
Lots of teams are hiring designers!
Please consider donating to help those affected by the war in Ukraine if you can. 🇺🇦