"Brand blue" is #2F5FDB in the Figma file, #2E5ED9 in the CSS, and #305FDA in the native app. Nobody chose three different blues on purpose. Someone eyedropped a screenshot once, someone else typed a hex code from memory, and a design system that was supposed to be a single source of truth quietly became three sources that mostly agree. Design tokens are the fix everyone reaches for. Most implementations still end up as a second source of drift instead of the cure, because the pipeline around the tokens was never built with the same care as the tokens themselves.
This guide covers how to structure a token pipeline that designers and developers both actually trust: what a token is for, how to tier them so they don't collapse into a flat list of hex codes, how to wire the handoff from design tool to codebase, and how to govern the thing so it doesn't rot six months after launch.
Photo by cottonbro studio on Pexels
What a token pipeline actually solves
A design token is a named, platform-agnostic value: a color, a spacing unit, a font size, a border radius, a shadow. The token itself is not the hard part. Naming color-brand-primary as #2F5FDB takes five minutes. The hard part is making sure that value exists exactly once, gets consumed identically by every platform that needs it, and stays correct when someone changes the brand blue eighteen months from now.
Without a pipeline, tokens are just documentation. A page in Figma or Notion that says "here are our colors" is a snapshot, and snapshots go stale the moment someone ships a component without checking it. A real pipeline treats the token values as the actual source of truth that code and design files both pull from, so drift becomes structurally difficult instead of a matter of discipline.
Pick a format before you pick a tool
The design tooling landscape changes faster than most companies' design systems. The tool you standardize on today may not be the tool you use in three years. What should not change is the format your tokens are stored in. The W3C Design Tokens Community Group has been working toward a shared JSON schema specifically so tokens defined once can move between Figma, Style Dictionary, Tokens Studio, and whatever comes next without a full rewrite.
Adopting that format, or something close to it, early saves a painful migration later. Teams that hand-roll a proprietary token schema tied to one tool's export format tend to discover the cost only when they try to switch tools, at which point every consuming codebase needs to be touched.
Structure tokens in tiers, not a flat list
A flat list of a few hundred named colors and sizes looks organized at first and becomes unmanageable within a year. The pattern that holds up is a three-tier structure.
Core tokens are the raw palette: blue-500, space-4, font-size-16. These are context-free values with no opinion about where they're used. Designers rarely touch these directly once they exist.
Semantic tokens map core values to a purpose: color-text-primary points at gray-900, color-surface-danger points at red-100. Semantic tokens are what most designers and developers actually reference day to day, because the name describes intent rather than a raw value.
Component tokens are the most specific tier: button-primary-background points at a semantic token, which points at a core token. Component tokens exist so a single component can be restyled without touching the semantic layer that dozens of other components also depend on.
The tiering matters because it isolates change. Rebranding the primary color means updating one core token and letting the semantic and component layers inherit the change automatically. Without tiers, a rebrand means grepping for every hardcoded reference to the old value across every platform, which is exactly the problem tokens were supposed to prevent.
Photo by Eugene Capon on Pexels
Wiring the pipeline from design file to code
The mechanical piece most teams underestimate is the handoff itself. A typical pipeline looks like this: designers manage token values inside Figma, using either native Figma Variables or a plugin like Tokens Studio, which exports to the shared JSON format described above. A build tool, most commonly Style Dictionary, consumes that JSON and transforms it into whatever each platform needs: CSS custom properties for web, a Swift or Kotlin file for native apps, a SCSS map for older stylesheets still mid-migration.
That transform step is where most of the leverage lives. Instead of a developer manually translating "the designer said the border radius is 8px" into a CSS variable, the build step generates the CSS variable directly from the same JSON the design file exports. The MDN documentation on CSS custom properties covers the consuming side on the web, where tokens typically land as --color-text-primary style variables that components reference instead of hardcoded values.
The pipeline should run on every token change, not on a manual schedule. A GitHub Action or equivalent CI step that regenerates platform outputs whenever the token source file changes turns "someone remembered to export tokens" into "the pipeline just runs," which is the difference between a system that works for a quarter and one that works for years.
Theming and multi-brand support
Semantic tokens are also what makes dark mode and multi-brand theming tractable. Instead of writing a second full set of component styles for dark mode, you swap which core token each semantic token points to. color-surface-primary points at white in light mode and gray-900 in dark mode; every component that consumes the semantic token gets the correct value automatically, with zero component-level code changes.
The same mechanism extends to multi-tenant products that need per-client branding. A tenant's brand color becomes a core token override, the semantic layer stays untouched, and the components never know a theme swap happened. Teams that try to retrofit theming onto a system built on hardcoded values usually end up doing a much larger rewrite than the token-based approach would have required from the start.
"The teams that get the most value out of tokens are the ones who treat the semantic layer as the real product. The core palette is just inventory. The semantic names are the actual design decisions, and that's the layer worth protecting when a rebrand or a new theme comes through." - Dennis Traina, founder of 137Foundry
Governance: who owns a token change
A token pipeline without governance drifts into the same mess it was built to prevent, just with extra tooling. Two rules cover most of what a team needs.
Every new token needs a reason to exist. Before adding color-button-hover-state-alt-2, someone should be able to answer "why isn't this the same as an existing token?" Left unchecked, component-tier tokens multiply until nobody can tell which one is actually in use, and the token list becomes as unmanageable as the hardcoded values it replaced.
Token changes go through the same review as code changes. A pull request that changes a core color value should require sign-off from whoever owns the visual design, not just whoever happens to be touching the CSS that day. Treating token files as design artifacts that live in version control, reviewed like code, keeps design and engineering accountable to the same source of truth instead of two teams maintaining their own copies.
Photo by Vitaly Gariev on Pexels
Testing tokens before they ship
A token change that looks correct in isolation can break a dozen components that depend on it. Visual regression testing catches this class of bug before it reaches production. Tools like Storybook let a team render every component variant against the current token set and snapshot the output, so a semantic token change that accidentally makes body text unreadable on a dark background gets caught in review instead of by a user.
The testing discipline matters more for semantic and component tokens than for core tokens, since a change at the semantic layer fans out to every component that references it. A small suite covering the highest-traffic components, checked on every token pull request, catches the majority of regressions for a fraction of the cost of full coverage.
Rolling out a token pipeline on an existing product
Teams starting from a codebase full of hardcoded hex values rarely need to migrate everything at once. The workable rollout order is: define the core and semantic tiers first, wire the build pipeline, then migrate components incrementally as they're touched for other reasons rather than in a dedicated migration sprint. New components use tokens from day one. Existing components get migrated opportunistically, with a tracked list so the migration doesn't quietly stall at sixty percent forever.
Trying to migrate an entire product's styling to tokens in one release is where most token initiatives lose momentum. The incremental approach produces slower visible progress but a much higher completion rate, because it doesn't compete with feature work for a dedicated block of calendar time that's easy to deprioritize under deadline pressure.
Common failure modes worth naming
A few patterns account for most token pipelines that quietly stop working. Tokens defined in two places happens when a plugin export and a hand-maintained JSON file both claim to be the source of truth; pick one and delete the other. No build automation happens when token updates require someone to remember to run an export script; wire it into CI so it can't be forgotten. Flat naming with no semantic layer happens when a team jumps straight to component tokens without the semantic tier in between, which reintroduces the exact fragility tokens were meant to remove. Governance that exists only in a wiki page happens when the review process isn't actually enforced anywhere, so it quietly stops happening under deadline pressure.
Each of these is a process gap rather than a tooling gap. The tools involved, whether Figma Variables, Tokens Studio, or Style Dictionary, are mature enough to support a well-run pipeline. What fails is usually the discipline around them, not the software itself.
Bringing design and development back into agreement
A design token pipeline is ultimately a communication tool wearing engineering clothes. Its job is to make sure that when a designer says "brand blue" and a developer writes color-brand-primary, they are, byte for byte, talking about the same thing. Get the tiering right, automate the build step so it can't be skipped, and put real review on top of token changes, and the pipeline stops being a project that needs maintaining and starts being infrastructure nobody thinks about, which is exactly what a good pipeline should feel like.
If your team is weighing whether to build this in-house or bring in outside help to stand up the pipeline correctly the first time, 137Foundry's services page covers the design-to-code work we do for teams in exactly this position, and the about page has more on how we approach that kind of engagement. Either way, the earlier a team adopts a real tiered structure instead of a flat list of hex codes, the less painful the eventual rebrand or dark mode launch turns out to be. For more on how we think about the broader design-and-engineering handoff, 137foundry.com is a good place to start browsing.
