How I Think About Starting With Variables
A Simple Way to Get Unstuck 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 so 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 Way to Get Unstuck
One very simple approach 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.
If this way of thinking is helpful, I hope it makes starting feel a little less daunting! I’ll be sharing more thoughts like this as the year gets going, and hope to see you there.
Thanks for reading! Take care. đź’›
– Joey
In case you missed it...

In case you missed it, I also teach a course called Level Up with Figma. Just over 3,000 designers have gone through it so far.
The course includes nearly 30 modules covering Figma foundations, shortcuts, and the workflows I use daily when designing and building libraries and design systems.
If you or your team are interested in joining the upcoming cohort, you can use the code newsletter for 20% off enrollment. I’d love to have you there! 🎓