Demystifying design tokens: a beginner's guide
Design tokens are named entities that store the raw values of your visual styles. Hex codes, pixel sizes, type scales. A good token does more than store a value: its name carries the decision about where that value belongs. Seeing the token tells you how to use it.
Think of tokens as nicknames for raw values. But they are not only storage. The point is that this stored data flows into the development pipeline. Tokens live in a technology-agnostic format like JSON, which any design or engineering platform can consume. That is why people call them a single source of truth.
Life before and after tokens
Say a color in your design system needs to change.
- Designer updates the hex code in the design tool.
- The new value is handed off in a conversation.
- Developer re-types the value in code.
- Designer checks production and chases what got missed.
- ↺ repeat for every value, forever
- Designer updates the raw value once.
- The pipeline translates tokens to each platform's format.
- Developer pulls the update like any code change.
Without tokens, the designer updates a hex code, hands it off in a conversation, the developer re-types it in code, and the designer later checks production hoping it landed right. On a small project that feels survivable. Do it for every value change, forever, and the workflow quietly eats your weeks. The developer spends attention on retyping colors instead of real work. The designer spends attention on policing production instead of UX.
With tokens, the designer updates the raw value once, the pipeline translates it into whatever format each platform needs, and the developer pulls the update like any other code change. No verbal handoff, far fewer mistakes.
Why tokens earn their keep
Consistency. Your system holds many colors, sizes, and type styles, and every one of them carries decisions: this color, on this component, in this state. Keep those decisions in your head and you will misremember them, one screen at a time, until the system rots.
Communication. You cannot tell a developer, this button is #4169E1, please memorize it. Without tokens and documentation, developers end up eyedropping values off your mockups, and production drifts away from the brand.
Translation. Tokens stored as code can be converted by tools like Style Dictionary into whatever engineering needs: css, sass, swift, flutter. Push the update, pull the update, done.
If a design system is a country, design tokens are its national language.chaw su · explaining tokens to a cohort
You are closer than you think
If tokens still feel foreign, look at what you already do. If you set up style guides before starting a product, Figma local styles are familiar. If you name your hex codes blue-500, red-100, success-700, you are already using the most basic base tokens.
Tokens are not a tool. They are a methodology every designer should practice.
Choices and decisions
Tokens come in two kinds. Choices, also called base or global tokens, store the raw values you picked: your palette, your scale. Decisions, also called alias or semantic tokens, point a choice at a use case: this base color is the primary button background.
#4169E1color-blue-500button-background-primaryHow to start inside your style guide
Start by tokenizing the values you already chose: #4169E1 becomes blue-500. Figma variables or Tokens Studio can store these in the design tool.
Then add the decision layer: blue-500 becomes button-background-primary, tied to where it is used.
Export the tiers as JSON, translate them into the formats your product teams need, and write the documentation while it is fresh. The workflow between design tools and code still needs plugins to bridge it, but the method stands regardless of tooling.
This is the first episode of a series. The next one goes deeper into token tiers and naming systems.