Design tokens sound like something only a large product team needs. The underlying idea is simple enough, though, and it solves a problem every project has: the same value written in forty places, forty chances for it to drift.
What a token actually is
A token is a named value. Instead of writing `#3753d4` wherever you need your brand blue, you name it `colour/brand/primary` and use the name.
That's it. The power isn't in the concept, it's in what the name buys you:
- Change it once. Update the token, everything using it updates.
- It means something. `colour/text/secondary` tells you where to use it. `#5f6169` tells you nothing.
- It survives redesigns. A token called `blue` becomes a lie the day the brand changes. One called `brand/primary` doesn't.
- It crosses tools. The same token name can exist in Figma, in your CSS, and in your component library.
How Figma variables fit
Figma variables are Figma's implementation of tokens. Four types:
- Colour — fills, strokes, text
- Number — spacing, radius, sizes
- String — text content, useful for swapping between languages or states
- Boolean — show and hide, for variants
The feature that makes them worth the setup is modes. One variable can hold different values in different contexts — light and dark, compact and comfortable, one brand and another. Switch the mode on a frame and everything inside re-resolves.
That's how a properly built file shows you a dark version of an entire page without a second set of screens.
Aliasing, which is where it gets useful
You can point one variable at another. This produces two layers:
Primitives — the raw palette. `blue/500 = #3753d4`. These rarely change and are never used directly.
Semantic tokens — what things are for. `text/link = blue/500`. `button/primary/background = blue/500`. These are what you actually apply.
The benefit: when you decide your links should be a different shade, you change one semantic token rather than hunting through every use of `blue/500` to work out which ones were links.
Mapping to the build
In CSS, semantic tokens become custom properties:
Your `colour/brand/primary` becomes `--brand-primary`, declared once on `:root` and used everywhere. Dark mode is the same variable redeclared inside a media query — exactly the same idea as a Figma mode.
In Webflow, they become variables in the Designer, which have worked the same way since Webflow added them. You define your colours, sizes and fonts as variables, use them on classes, and change them in one place later.
The practical upshot is that a designer and a developer end up using the same names for the same things, which removes an entire category of translation error.
When a small team needs this
Honestly? Not always.
Worth it if you have more than one designer, more than one product or brand, a dark mode, several breakpoints with different spacing, or a site you expect to restyle rather than rebuild.
Overkill for a five-page marketing site built once by one person. Styles and components will do fine, and you can add variables later without redoing the file.
The middle ground most small studios land on: use variables for colour and spacing, skip everything else, and expand only when a real need turns up.
A sensible starting structure
If you're setting this up for the first time, this covers most of it without becoming a project in itself:
- `colour/brand/` — primary, secondary, accent
- `colour/text/` — primary, secondary, muted, inverse
- `colour/surface/` — page, raised, sunken
- `colour/border/` — subtle, strong
- `colour/state/` — success, warning, error, info
- `space/` — your scale, as numbers
- `radius/` — none, small, medium, full
Seven groups. An hour to set up. Everything after that is a refinement rather than a rebuild.
Mistakes worth avoiding
Naming for appearance. `blue-600` is a primitive and that's fine, but if your semantic layer is also called `blue`, you've built a system that lies to you the moment the brand changes.
Skipping the semantic layer entirely. Applying primitives directly works right up until you need to change one use of a colour without changing the others.
Too many primitives. A full 50-to-900 ramp for six colours is 54 values you'll never use. Start with the shades you actually have.
Modes for things that aren't modes. A mode is a context the whole design switches into — light and dark, one brand and another. A single component's variant is a variant, not a mode.
Building it before you need it. Tokens describe decisions you've already made. If the design isn't settled, you'll spend the week renaming things.
A quick way to test whether yours is working
Try to change your brand's primary colour to something completely different — a green, say — and see how long it takes.
If it's one edit and the whole file updates, including the dark variant, the system is doing its job. If you're hunting through layers, the tokens exist but nothing is actually using them, which is the most common state for a half-finished system.
Questions we get asked
Do variables replace styles in Figma?
Not entirely. Variables handle single values — a colour, a number, a string. Styles still handle compound properties like a full text style or an effect. Most teams use both.
Can tokens be exported straight into code?
There are plugins and pipelines that do it, and they work well for product teams shipping to a component library. For a marketing site it's usually simpler to keep the names consistent by hand — the same token names in Figma and in your CSS or Webflow variables — and skip the tooling.
We're a two-person team. Is this worth it?
The colour and spacing part, yes — it's an hour's work and it pays for itself the first time you restyle something. Modes, aliasing and export pipelines can wait until you have a reason.
If you're setting up a system for the first time and want a second opinion on the structure, we're happy to take a look at what you have.