Figma is a revolutionary cloud-based design platform that simplifies team collaboration and absolutely crushes the risk of losing your work from unwarranted crashes (I’m looking at you, Adobe). With that said, it’s still relatively young and is always evolving. It wasn’t too long ago that powerful features like Auto Layout and Variants were still on our wish list (not to mention Smart Animate, gif support, and plugins). If you’re like me and always striving to keep up with the latest and greatest, you’re going to want to learn how to apply Auto Layout and Variants to your design systems. But I’m not going to lie, it’ll take some getting used to. These tools require you to adhere to a disciplined architecture and forbid quick-and-dirty, experimental changes to frames (a.k.a artboards).

So is it worth it? Absolutely, and here’s why.

First Things First: What Are We Talking About?

Auto Layout

In the most simplistic terms, Auto Layout allows you to combine multiple layers into a single row or a single column, with each layer equidistant from the next.

When you combine layers with Auto Layout, it will wrap them in a “frame.” Like with any other frame in Figma, Auto Layout frames can be nested.

The end result is the ability to build layouts fixed to a grid. You no longer have to worry about objects being a few pixels off your guide. Auto Layout will ensure that everything is always perfectly aligned.

Layers wrapped within an Auto Layout frame cannot be freely dragged around the frame. Depending on where you mouse-up, clicking and dragging on one of those layers will either (1) swap that layer with a sibling or (2) remove the layer from the frame. This restriction saves you from yourself: your designs need to adhere to a specific, purposefully designed and symmetrical architecture. This isn’t a recommendation–they literally have to. That doesn’t mean you can’t easily adjust spatial elements, it just means your adjustments will apply to the Frame at large, which is not only best practice anyway, but it’s also what your developer will do when converting designs into code (more on that later).

So what are some ways in which you can modify elements inside an Auto Layout frame?

First, I already noted that Auto Layout allows you to create a row or column. You can change any frame from one to the other by tapping the down arrow (for a column) or right arrow (for a row). You can also modify the “space between” each layer by increasing or decreasing the number besides the ]〡[ symbol. Additionally, you can adjust the full frame’s padding (a.k.a space around) by increasing or decreasing the number beside the ▣ symbol. And finally, you can determine how you want layers to align themselves, relative to the Auto Layout frame. They can be aligned in any direction along the X, Y axes (i.e., top-left, top-center, top-right, center-left, center-center, center-right, bottom-left, bottom-center, bottom-right).

In addition to those explicit Auto Layout controls, there are constraints to Auto Layout frames that Figma calls “Resizing.” Resizing allows you to dictate whether the height and/or width of an Auto Layout frame “hugs” its content (i.e., its dimensions match content dimensions), fills the space of its parent container (i.e., its dimensions match the dimensions of the container it’s inside), or remains set to a fixed width regardless of its content or its parent (i.e., its dimensions are manually set by you and will not change unless you change them). In practice, this means that you can have simple luxuries, like a component’s height auto-adapting to the amount of text inside it. Or an advanced form naturally adjusting to additional input fields. Or an entire page adapting to the addition or subtraction of various elements. All without having to refine spacing or manually move other components on the page.

Variants

In order to understand Variants, you need to first have a baseline understanding of Figma Components. For those of you coming from the world of Sketch, you’ll know components by a different name: “Symbols.” Both Components and Symbols are conceptually synonymous with “templates.” In other words, they allow us to create a master template of a design. Whenever we duplicate the master, we create an “instance” of the original. The instance always matches the master, so any changes made to the master will cascade to every instance. This can save you a lot of time and minimize the risk of generating inconsistent designs over time. For example, let’s say you convert a red button into a component. If you decide to change that red button to blue, every instance of that button across your design system will also change to blue. That is to say, you don’t have to manually update every button–you just have to update the first one you created. Another way of looking at this is a parent and child relationship: the parent sets the rules and the child follows them.

But what if you want multiple buttons? For example, a primary button and a secondary button. In that case, you’d create two components: one called “primary” and another called “secondary.” You’d then group these components by naming each one with Figma’s naming syntax. The syntax looks like this:

[Category] / [Subcategory] / [Sub-subcategory] / […]

In the case of our buttons, we have one category (i.e, buttons) and two subcategories (i.e, primary and secondary). So the name of our primary button would look like this:

Buttons / Primary

And the name of our secondary button would look like this:

Buttons / Secondary

And Figma would display them in its sidebar like this:

As you can see, Figma grouped both instances into a folder called “Buttons.” We only used one sub-category for this example, but you can have as many as you need. For example, perhaps I want an active and inactive state for each type button. That would look like this:

1. Buttons / Primary / Active
2. Buttons / Primary / Inactive
3. Buttons / Secondary / Active
4. Buttons / Secondary / Inactive

As powerful as this syntax is, imagine applying it to more complex components…or even components nested within components (such as a button component inside a form component inside a header component). The larger your design system, the more tedious, time intensive, and error prone this process becomes.

Enter: Variants. A variant is exactly what it sounds like: it’s a variation of a single component. In our example above, we have four independent components grouped with a smart syntax.

If you select each one and click on the “Combine as Variants” button in the sidebar, each of those components will merge into a single component made up of four variations.

In the image above, you can see that each button is now contained within a single component. On the right side, the button to combine variants has been replaced with two rows of properties. Property 1 lists the type of button (e.g., Primary or Secondary) and Property 2 lists the state of the button (e.g., Active or Inactive). By clicking on a property’s name, you can rename it. For example, I renamed these “Type” and “State.”

If you copy an instance of your button variant, you’ll see the option to change which variant is being applied to the instance.

It’s that simple, but it can be even simpler. If you rename the “State” property to “Active” and change the values to “True” or “False”, Figma is smart enough to convert the dropdown into a switch. When on, the active state is shown. When off, the inactive state is shown.

Figma is essentially treating properties as variables. Just like in math or with code, a variable is a name that equals a value. For example, if X = 10, then 5 + X = 15 because X is equivalent to the value of 10. Similarly, our properties require a name (e.g., “Type”) and a value (e.g., Primary or Secondary). This can be written in another way: Type = Primary.

In fact, Figma allows you to add properties, modify existing properties, or change properties’ values by using this exact syntax. If you take a look at the Layers panel, you’ll see each property written out using this syntax and separated by commas.

Double clicking on a variant will allow you to edit those properties however you like. Just make sure that whatever property you add to one variant is also added to every other variant within that given component. The values can be different, but the variant must exist. If a property is missing from a variant, Figma won’t know how to treat it because it hasn’t received a value where it expected to find one.

Ok, so what’s the value?

There are two prime value offerings. The first is incredible consistency and modularity. Since both auto layout frames and variants can be nested inside other frames and components, you can create pages in which anything from an entire section to a single button can be added, subtracted, or modified with a single flick of a switch.

This comes in handy when, for example, you’ve built a landing page template for the marketing team and they need to generate specific versions for each ad campaign. Or, to use a product-oriented example, when you need to switch a layout between various administrative permissions. Variants make it easy to do the switching while auto layout ensures that each version of your template is pixel perfect.

The second, and arguably more important, value offering is developer compatibility. Both Auto Layout and Variants speak code. You probably know that Figma has an “Inspect” tab that converts your designs into simple code to ease the pain of converting static designs into dynamic interfaces. What you may not know is that, until the advent of Auto Layout, Figma positioned elements “absolutely” within a frame. For those of you unfamiliar with absolute positioning, just know that in the world of responsive design, it’s an…absolutely…horrible idea (or, for those curious enough, learn more here). Instead of absolute positioning, modern frontend elements are positioned relative to one another (i.e., relative positioning). Auto Layout positions elements relatively, allowing developers to grab more meaningful code snippets from the Inspect tab. This may seem trivial, but it’s not. At the end of the day, nothing matters if the actual application doesn’t reflect the mockups. The more we can do to assist developers in achieving our vision, the better.

Great, now what’s the risk?

If you’re working with a team that’s unfamiliar or disinterested in these new tools, auto layout and variants may cause confusion and frustration. Both tools require discipline and neither enables quick and dirty adjustments to layouts. Directly editing an instance of a component (with variants enabled or otherwise) detaches it from the master, which stops it from inheriting updates until reset (and, you guessed it, a reset erases all of your overrides). On top of that, auto layout prevents modifications that aren’t inline with your previously defined grid architecture. This can lead to unfamiliar or simply irritated designers deleting auto layout frames as a quick work around.

In a lot of ways such workarounds make sense. Designs are born through an iterative process of trial and error. Ridgid tools do little to enable this behavior while doing much to stunt creativity. Therefore, in order to encourage their adoption, I advise designers to go to town on duplicate drafts of components and frames. Once they’ve finalized their vision in a draft, they can rearchitect the layout in Auto Layout and import it into the master component where it will automatically apply to all instances. For some, this process feels easy enough. For others, it feels cumbersome. In either case, a little extra work is a fair tradeoff for a much simpler, more sustainable, and more scalable design system.

Takeaway

Utilizing Auto Layout and Variants can decrease unwanted variability within your design system, simplify maintenance efforts, and ease the design-to-development process. But for that to happen, you and your team need to be committed. Unconvinced teammates will have a harder time devoting the added effort, leading to shortcuts and quick fixes scattered throughout your designs. Even a single inconsistent design pattern can confuse developers who, rightfully, will assume the deviations are intentional. This slows development time and, in worst case scenarios, leads to an incorrect UI within the live application.

With that said, an adjustment period is entirely warranted and well worth the payoff. For wary teammates, I recommend hosting a few lunch-and-learns in which you lead your team in example projects. Figma actually offers excellent educational resources for both Auto Layout and Variants that you can find here and here, respectively.

If you have additional questions or comments after reading this article, feel free to join the discussion in the comments below.