Using Figma Variables & Design Tokens

Figma Variables are named, reusable values — colors, spacing, numbers, strings, and booleans — that you define once and apply across every layer, component, and mode in a file. Instead of hand-editing a hex code on fifty different frames, you edit the variable once and every layer bound to it updates instantly. This tutorial shows how to set up a basic token system in Figma, organize it the way a real storefront design system would, and apply it to a theme file such as our Figma themes, including the Optics Figma theme we use as a worked example.

If you have ever renamed a brand color and then spent twenty minutes hunting through layers to update every instance of it, this is the feature that fixes that problem for good.

What Design Tokens Actually Are

Design tokens are the smallest reusable decisions in a design system — a specific blue, a specific spacing unit, a specific font size — each given a name instead of being used as a raw value. The idea predates Figma; teams building design systems in code have used token systems (often exported as JSON and consumed by CSS-in-JS or Tailwind config) for years. Figma Variables are Figma's native implementation of the same concept, built directly into the layers panel so designers can apply tokens without leaving the design tool.

The payoff of using tokens instead of raw values comes in three places: consistency (every button uses the same blue because it references the same variable, not because someone eyeballed it), speed of change (rebrand a product by editing a handful of variables instead of thousands of layers), and handoff (a developer implementing the design can map each Figma variable to a CSS custom property or theme value one-to-one, instead of guessing which of twelve near-identical grays was intentional).

The Four Variable Types in Figma

Figma Variables support four data types, and knowing which to use where keeps a token system from turning into a junk drawer.

• Color — the type you will use most. Backgrounds, text colors, borders, icon fills.
• Number — spacing values, corner radius, stroke weight, font size, and grid gutters.
• String — font family names or content placeholders that need to swap between modes (for example, swapping a label between languages).
• Boolean — toggles used mostly with component properties, such as showing or hiding an icon slot.

Step 1: Open the Variables Panel and Create a Collection

In a Figma file, open the right-hand panel and look for the local variables icon (it sits alongside local styles). Create a new collection — think of a collection as a named group of related variables, similar to how a stylesheet groups related CSS custom properties. A typical storefront project benefits from at least two collections: one for primitive values and one for semantic values, which mirrors the two-tier token approach used in modern CSS design systems (raw values feeding named roles).

Step 2: Build the Primitive Layer

Primitives are your raw palette: the actual hex codes and pixel numbers with no meaning attached to them yet. Name them by what they are, not what they are used for, following a pattern like:

• color/blue-100 through color/blue-900 for a full blue ramp
• color/gray-100 through color/gray-900 for neutrals
• space-1, space-2, space-3... following a consistent scale (commonly 4px increments)
• radius-sm, radius-md, radius-lg for corner rounding

Keep this layer boring on purpose. Nobody should ever apply color/blue-600 directly to a layer in a finished design file — it exists only so the next layer can reference it.

Step 3: Build the Semantic Layer

This is the layer designers actually use day to day, and it is where tokens earn their keep. Semantic variables describe role, not raw value: bg-surface, text-foreground, text-muted, border-default, accent, bg-danger. Each semantic variable points to a primitive variable rather than a raw hex code. For example, accent might reference color/blue-600 in one collection alias and a different blue for a seasonal promo theme, without touching a single component.

This two-tier structure (primitives feeding semantics) is the same pattern used in well-built CSS token systems, where a raw palette feeds a smaller set of named roles that components actually consume. If you have ever worked in a codebase with a rule like "never use raw gray/slate/neutral utilities, only semantic role tokens," Figma Variables let you enforce the design-side equivalent of that rule before code is even written.

Step 4: Set Up Modes for Light and Dark (or Multiple Brands)

Every collection in Figma supports modes — alternate value sets you can switch between without duplicating layers. The most common use is light and dark theme support: create a "Light" mode and a "Dark" mode inside your semantic collection, then set different primitive references for each. bg-surface might point to a near-white primitive in Light mode and a near-black primitive in Dark mode, while every component that references bg-surface switches automatically when you flip the mode on a frame.

Modes are also useful beyond light/dark — a multi-brand storefront system, or a single theme file offering a few accent-color variants, can use the same mechanism. This maps directly onto how modern storefronts implement theme-swapping: the same component markup, different token values loaded per theme.

Step 5: Bind Variables to Layers

With your collections built, go back to your actual designs and bind properties to variables instead of leaving them as static values. Select a layer, open its fill, and instead of picking a color from the swatches, click the variable icon and choose the semantic variable that matches its role (bg-surface for a card background, text-foreground for body copy, border-default for a divider line). Do the same for spacing values in auto-layout frames — padding and gap can bind to your space-* number variables just like fills bind to color variables.

This step is the one teams most often skip under deadline pressure, and it is also the one that determines whether the rest of the system actually pays off. A file full of unbound layers with variables defined but unused gives you none of the benefits — the point is that editing a variable's value should visibly update the canvas.

Step 6: Apply the System to Components

Once your base variables are bound to raw layers, build (or update) your components to inherit those bindings. A button component should get its background from accent, its text from a contrasting semantic token, and its padding from your spacing scale — never from a value typed in directly on the component itself. Because component instances inherit from their main component, a well-tokenized base component means every instance across every page stays correct automatically, and switching modes on a frame that contains the component updates it instantly.

This is exactly the structure our Figma theme kits are built around: a primitive layer, a semantic layer, and components that consume only the semantic tokens. Working from a theme file organized this way (rather than a flat file of hand-styled screens) means a merchant or designer can reskin an entire storefront — accent color, surface tones, corner rounding — by editing a handful of variables rather than hunting through every screen.

Step 7: Handing Tokens Off to Development

Once your variable structure is solid, handoff to a developer becomes a mapping exercise rather than a guessing game. Each semantic variable in Figma should have a clear counterpart in code — commonly a CSS custom property or a value inside a Tailwind theme block. If your semantic variable is named bg-surface, the CSS token should also be named something recognizably equivalent, so a developer reading the Figma inspector panel and a developer reading globals.css are looking at the same mental model. Figma's Dev Mode surfaces the variable name directly in the inspector, which is far more useful to an implementing developer than a raw hex value with no context.

Some teams take this further and export variables as JSON (through Figma's REST API or community plugins) to auto-generate the corresponding code tokens. That is a reasonable next step once your team is mature enough to want a single source of truth, but it is not required to get the core benefit — even a manually maintained one-to-one naming convention between Figma variables and CSS tokens removes most of the ambiguity in design-to-code handoff.

Common Mistakes to Avoid

• Naming by value instead of role in the semantic layer — a variable called blue-button instead of accent breaks the moment the brand color changes.
• Skipping the primitive layer entirely — binding components straight to raw hex-named variables works short term but makes theme variants and rebrands much harder later.
• Leaving legacy styles and variables running side by side — mixing old Figma Styles with new Variables in the same file causes confusion about which system is the source of truth. Pick one and migrate fully.
• Over-fragmenting the spacing scale — a spacing scale with twenty near-identical values defeats the purpose of a scale. Keep it to a small, deliberate set (commonly 6-10 steps).
• Forgetting to test mode switching before shipping — always toggle every mode on a full page, not just a single component, to catch anything left unbound.

Where This Fits With Polo Themes

Our Figma products are built with this exact primitive-to-semantic structure so buyers are not just getting static screens — they are getting an editable system. Whether you are working from the Optics Figma theme, the Medical Figma theme, the Wosa fashion Figma theme, the Course Whiz Figma theme, or exploring options across the full Figma theme bundle, the variable structure works the same way: change a handful of semantic tokens and the entire storefront concept restyles consistently, rather than requiring a screen-by-screen rebuild.

If you are choosing between a Figma theme and a ready-to-launch Shopify theme, browse our full theme catalog to compare — Figma files give you full design control before a single line of code is written, while Shopify themes get a store live immediately. Many merchants use both: a Figma file to plan and customize the visual system, then a matching Shopify theme to launch.

Frequently Asked Questions

Do Figma Variables replace Figma Styles?

For most new work, yes — Variables are more flexible because they support modes (light/dark, multi-brand) and can hold numbers and strings in addition to color, which Styles never supported. Existing files built entirely on Styles do not need an emergency migration, but new token systems should be built on Variables.

How many modes should a typical collection have?

Start with what you actually need — often just one, or two if you are supporting light and dark. Adding modes speculatively before there is a real use case just adds maintenance overhead; it is easy to add a mode later once the underlying variable structure is already solid.

Can developers use Figma variable names directly as CSS variable names?

Not automatically, but you should aim for a close, predictable mapping. A Figma variable named bg-surface mapping to a CSS custom property like --color-bg-surface (or a Tailwind theme key of the same name) keeps design and code vocabulary aligned, which is far more valuable than the exact syntax matching character for character.

Is a token system overkill for a small storefront project?

Even a small project benefits from a lightweight version — a handful of semantic color and spacing tokens takes little extra setup time and pays off the first time you need to adjust a brand color or add a dark mode. The overhead scales with ambition: a single-page brochure site may not need modes at all, but a multi-page storefront concept almost always benefits from at least the primitive-to-semantic split described above.