Design Tokens – To Building Components That Scale

Introduction

As designers, there is a version of this scenario most of us have lived through. You are deep into a product, the brand palette is changing, and suddenly you are spending an afternoon tracking down every button, card, and banner across 20 Figma files, manually updating colours, hoping you have not missed anything. Three hours later, you find a rogue button in a file no one remembered existed, still wearing the old blue.

This is not a workflow problem. It is a system problem. And design tokens are one of the most effective ways to fix it.

Tokens might sound like a developer concern, but the decisions behind them. What to name, how to organise, what deserves a token, are fundamentally design decisions. They connect the choices we make and the way those choices get built, maintained, and scaled. Getting them right changes how your whole team works. Getting them wrong means your design system quietly accumulates debt every time someone takes a shortcut.

This blog will guide you through what design tokens are, how they connect to components you build, and how to set up a workflow that takes a design decision all the way from Figma to production efficiently.

What Is a Design Token?

A design token is a named design decision. Instead of a button having a hard coded fill of #2563EB, it references a token, a named variable that holds that value. Change the token once, and everything referencing it updates everywhere, instantly!

Tokens work in two layers, and understanding the difference between them is what separates a useful token system from one that just renames what you were already doing.

Primitive Tokens: The Raw Values

Primitive tokens are your foundational palette — values stripped of any context or intent. They simply describe what a value is:

color.blue.500 — #3B4EF8
font.size.md — 16px
font.weight.bold — 700
spacing.8 — 8px

Primitive tokens do not carry context or intent — they are simply the options available to your system.

Semantic Tokens: The Meaning Layer

Semantic tokens sit on top of primitives and give them purpose. This is where the real design thinking lives:

button.primary.bg — the background of your main call-to-action
text.heading.h1 — the style for your primary heading
spacing.card.padding — the internal breathing room inside a card

A semantic token does not just tell you what value is used, tells you where and why. That context makes a token system navigable for everyone, not just the person who built it.

Name for meaning, not for value

The easiest trap when setting up tokens is naming them after what they look like. color.blue.500 is technically accurate, but color.brand.primary is useful, it communicates intent. Anyone encountering it, designer or developer, immediately understands why it exists.

A clean naming structure follows three parts:

Category (color, spacing, font) → Concept (button.primary, text.heading) → Property (bg, size, weight, radius).
A well-named token tells you everything before you even check its value.

From Tokens to Components to Design Systems

Step 1: Tokens Power Individual Components

Once your tokens are in place, they become the building blocks of every component you design. Instead of a button storing its own colour value, it references button.primary.bg. Instead of a card hardcoding its corner radius, it points to radius.card.default. Every visual decision made for a component will be traced back to a token.

This matters because it means components stay honest,they never drift from the design decisions your token system has defined. A button built on tokens cannot accidentally become a slightly different shade of blue. It references the token, and the token holds the truth!

When you map it out for every component, the depth becomes clear. A content card actually contains design decisions across:

Colour — card background, heading text, body text, button fill
Spacing — card padding, internal gaps, button padding
Typography — heading size and weight, body size
Radius and Shadow — corner rounding and elevation

Each of those is a design decision worth naming and every decision that you name correctly is one you will never hunt down manually again.

Step 2: Components Assemble Into a Design System

Once individual components are token-backed, they naturally compose into a larger system. Think of it as a stack where every layer is built on and inherits from, the one beneath it:

Tokens — the foundation, every decision references these
Base Components — buttons, input fields, tags,  built directly on tokens
Composite Components — forms, navigation bars, carousels,  assembled from base components
Page Templates — full layouts assembled from composite components

Because inheritance flows downward, a change at the token level propagates upward through the entire stack. You update one value, and every component that references it, directly or indirectly, reflects that change.

Step 3: The System Scales Without Breaking

This is where the real payoff shows up. Imagine the brand colour changes. Without tokens: 50 buttons updated manually across 20 files, inconsistencies creeping in, and a follow-up audit to find everything that got missed. With tokens: one value updated, everything consistent, done in under a minute.

That same principle holds as your product grows — more screens, more teams, more components. The token layer ensures that no matter how large the system gets, decisions stay connected to a single source of truth.

Build Once, Theme as Many Times as You Need

Once components are built on tokens, theming becomes a configuration switch rather than a redesign. A single button can support primary and secondary styles, light and dark modes, and entirely different brand themes, without rebuilding anything:

What stays constant – layout, spacing, border radius , shared tokens that hold across every theme
What changes per theme – colours only, mapped to semantic tokens that resolve differently per mode

Switching modes is a single toggle in Figma’s Variables panel. No duplicate components, no version drift. For teams managing multiple clients or product lines, design once and theme as many times as the brief demands.

The Design-to-Development Handoff & How Tokens Fix It

Tokens fix the oldest handoff problem in design: the translation gap. Instead of hex codes and pixel annotations, the same decision carries the same name from Figma to code:

color/button/primary/bg in Figma — –color-button-primary-bg in CSS
spacing/card/padding in Figma — $spacing-card-padding in SCSS
font/heading/h1 in Figma — typography.heading.h1 in JavaScript

What Developers Actually Need From You

When designs are built on tokens, handoffs get simpler. Developers do not need hex codes or pixel annotations — they need token names, documentation explaining what each token is for, clear component structure, and usage guidelines (including what not to do). With Figma’s Dev Mode, they inspect a component and see variable names directly. That is the difference between guessing and knowing!

The Four-Step Workflow: From Figma to Production

Design — Build components using named tokens in Figma, not raw values
Inspect — Developers use Dev Mode to see token names, not raw values
Export — Tokens are converted to CSS, SCSS, or JSON via Tokens Studio or Style Dictionary
Implement — Developers reference token names directly in code. No translation layer, no back-and-forth

The Tools Worth Knowing

Token Management

• Figma Variables (native)
• Tokens Studio
• Figr Identity

Inspection, Handoff & Documentation

• Figma Dev Mode (native)
• Zeroheight / Supernova / Storybook

Documentation: The Part Teams Skip & Then Regret

A well-structured token system still creates confusion if people do not know what each token is for, when to use it, and when not to. Good documentation for each token should cover:

Name – e.g. color/button/primary/bg
Resolved value –  e.g. #2563EB
Purpose –  what this token is designed for
Usage guidance – where it should be applied
What not to use it for – equally important, and equally often skipped

When this is accessible and maintained, teams stop guessing, developers stop repeating the same clarifications, and new people onboard faster. When the system evolves, the documentation evolves with it.

Key Takeaways

• Name tokens for meaning, not appearance,  color.brand.primary will always outlast color.blue.500
• Map every design decision in a component to a token, not just the obvious ones
• Build components on shared tokens so theming becomes a toggle, not a redesign
• Give developers token names in handoffs, not hex codes or pixel annotations
• Start with Figma Variables, move to Tokens Studio when your system needs more
• Document what each token is for and what it should not be used for

Conclusion

Design tokens are still something many design teams treat as a developer’s concern. But the decisions behind them, what to name, how to organise, what deserves a token, are design decisions. The payoff for getting them right shows up everywhere: in how fast the team moves, how consistent the product looks, how smooth the handoff runs, and how much less rework lands on everyone’s plate when things need upgrades.

The best part of a well-built token system is that it eventually becomes invisible. The system holds, and the team gets to focus on the work that actually requires creative judgment. That is worth the upfront investment.