How I Think About Starting With Variables

Happy New Year, everyone! 👋 As I’ve been settling back into work, I’ve been thinking a lot about how teams get started with design systems work, especially when things feel big or intimidating. One area that comes up again and again is variable structure, so I wanted to share a simple way I’ve found helpful when I’m not sure where to begin.

Why Variable Structure Feels Hard

Variable structure is one of the areas that seems to trip teams up early. Not because variables are inherently complicated, but because getting started feels oddly intimidating. There’s a lot of pressure to “do it right,” especially given how many surfaces and people variables end up touching.

In many ways, it can feel like you’re responsible for setting the foundation of your product, and that foundation is expected to support every use case, across every surface, forever. That’s terrifying. And once teams start thinking about scale, platforms, themes, and modes all at once, it’s easy to freeze.

What Variables Actually Do

If you’re newer to variables in Figma, they’re a way to define and reuse shared values across designs and components. Instead of hard-coding colors, spacing, or states, variables let teams reference a single source of truth that can be updated and applied instantly and consistently.

Within Figma, variables can represent things like colors, numbers, strings, and booleans, which are useful for turning layers on and off based on the active mode. On their own, those types are fairly simple. What makes variables powerful is how they create relationships between components, states, and eventually, design and code.

When I’m thinking about variable structure, I’m mostly trying to answer one question: does this help the people on my team understand intent and behavior quickly?

A Simple Way to Get Unstuck

If you’re not sure where to begin, this distinction can be a really helpful way to get unstuck.

One simplification that’s worked well for me is separating variables into non-interactive and interactive buckets. When I’m staring at a design and tasked with creating a structure that’s easy to understand, implement, and scale, this approach almost always gives me a clear first pass. A way to get started. I can look at what’s on the screen and ask: what’s part of the environment, and what’s expected to respond to a user’s input?

Non-interactive variables describe the environment. Things like background surfaces, text, icons, and borders that don’t change based on input. Interactive variables describe behavior, such as actions, states, and feedback that do respond to input.

A Quick Example

As an example, think of everyone’s favorite component: the Button. The background color of the page, the default text color, and surrounding borders all fall into the non-interactive bucket. The Button itself introduces behavior and needs to display various states, such as hover, press, focus, or inactive. Those states live in the interactive group of variables.

Something I always try to keep in mind is that clarity beats completeness, especially at the beginning. Variable structures don’t need to be perfect to be useful. They just need to give teams a shared place to start.