Tokens Are Not Variables

Design tokens are the most misunderstood part of a design system.
People often treat them like simple variables — a color here, a border radius there, maybe a few font sizes sprinkled in for good measure. But that’s not what tokens are for. Tokens aren’t arbitrary values. They’re contracts.

A token is a shared agreement between design and code. It’s a promise that this blue is not just any blue — it’s the blue that means “primary action.” It’s a symbol of intent, not just a pigment.

---

Tokens: The Design System’s Source of Truth

Imagine you’re building a button. Your designer calls it Primary / Default, and you implement it with background-color: #0052cc;. Everything looks fine — until marketing launches a rebrand, design updates the palette, and your button suddenly looks like it’s from 2017.

This happens because your button wasn’t bound to a meaning. It was bound to a value.
Tokens fix that.

A design token might look like this:

{
  "color.background.primary": { "value": "{color.blue.500}" }
}
`

Here’s what this says:

“The background color of a primary button should inherit its meaning from the brand’s blue at level 500.”

That’s a semantic link. If the brand blue changes, your token automatically updates — without breaking the contract. That’s the magic.

---

Variables Are Local, Tokens Are Global

Developers love variables because they’re scoped, flexible, and easy to override. But design tokens play a different role. They live above the code — in the shared layer between Figma, CSS, and code logic.

Let’s clarify the difference:

| Concept | Scope | Purpose | | ------------ | ------ | ------------------------------------------------------- | | Variable | Local | Defines a value used in one environment (CSS, JS, etc.) | | Token | Global | Defines meaning across environments (Figma, CSS, Code) |

Tokens say “this is what we mean by primary.” Variables say “this is how we implement primary in this context.”

It’s the same relationship between concept and instance, or interface and implementation. Design tokens are the interface. CSS variables are the implementation.

---

Rad UI’s Token Philosophy

Rad UI treats tokens as the connective tissue between design and runtime. Every color, spacing, and motion primitive starts as a design token — defined in JSON, mirrored in Figma, and exported as CSS custom properties.

That looks something like this:

{
  "colors": {
    "accent": {
      "value": "{palette.blue.500}"
    }
  }
}

Becomes in Figma:

$colors/accent = {palette.blue.500}

And finally compiles into CSS:

:root {
  --rad-colors-accent: var(--rad-palette-blue-500);
}

This three-step reflection — Token → Variable → CSS Custom Property — ensures your design language is consistent everywhere. When a designer updates a Figma variable, the change ripples through to your production CSS on the next build.

No hardcoded values. No guesswork. Just a living, breathing system.

---

Figma Variables Meet Code Reality

When Figma introduced Variables, it changed how design teams think. But on its own, Figma’s variable system still lives in isolation. The missing piece is interoperability — the ability to export those variables into a format your code can consume.

That’s where Rad UI’s tooling comes in. It syncs design tokens and Figma variables so that what you see in the design file is literally what you ship in production. The background color in your Figma component and the --rad-colors-background in your CSS aren’t cousins — they’re the same entity.

---

Tokens as Contracts

A token isn’t a design preference. It’s a contract signed by both sides — design and engineering. It defines not only what the system looks like, but what it means.

• Designers promise to use tokens instead of arbitrary color values.
• Developers promise to implement tokens instead of redefining values.

When both sides honor that contract, you get a design system that scales — across brands, rebrands, and even platforms. A system where you can change the mood of an entire product by editing a few JSON entries instead of rewriting your CSS.

---

Why This Matters

Tokens are how teams stay sane as they grow. They bridge language gaps, prevent “rogue UI mutations,” and let your product evolve without tearing apart the codebase.

At Rad UI, we think of tokens not as static definitions, but as living bridges — each one connecting design intent to runtime expression.

That’s why we say: Tokens are not variables. They’re truth encoded.

---

Want to dive deeper into how Rad UI’s token system works with your design system? Stay tuned for the next post: “The Token Pipeline: From Figma to Production CSS.”