How Figma's Variable Color Tokens Are Quietly Rewriting the Rules of Design Handoff

Open any design file from 2022 and you'll likely find a familiar artifact: a neatly organized page called "🎨 Color Styles" with rows of swatches, each labeled with a hex code and a name like "Primary/Blue/500." It was the shared reference for design handoff, the page developers would check, screenshot or (let's be honest) squint at in the sidebar panel.

Now open a file from a team that fully adopted Figma's variable system in 2025 or 2026. That page is gone, not moved. In its place is something closer to a working agreement between design intent and code than a style guide.

This is more than a tooling update. Figma's color variables and token system grew from the initial Variables launch in mid-2023 through big collection and scoping improvements in 2025 and into 2026, and along the way they changed how design teams organize and communicate color. Teams at companies like Linear, Vercel and Notion have taken apart years of color architecture and rebuilt it so that color is contextual and semantic by default.

Below is how that's playing out, what it means for handoff, and why static hex codes aren't coming back.

The old way: color as a fixed address

Design handoff traditionally treated color as a lookup table. A finite list of hex codes mapped to names, exported as a PDF, a Notion doc, or a Confluence page that developers bookmarked and gradually stopped checking. That worked well enough when products shipped in a single theme with a single brand palette. It fell apart as soon as things got more complex.

The style guide model left a gap in translation. Designers thought in terms of intent: "this is a destructive action." Developers received an output: "this is #EF4444." Both sides maintained a mental mapping that lived nowhere in the actual system. It existed in Slack threads, in verbal explanations during sprint planning, and in the institutional memory of whoever set up the original color tokens.

Even Figma's own Color Styles, introduced years ago, reinforced this static model. They were global, flat and unaware of context. "Primary/500" meant the same thing whether it appeared on a light card, a dark modal, or a high-contrast accessibility mode. The style had no idea where it lived or how it should behave.

This architecture led to predictable failures. Dark mode bugs shipped because the style guide only documented light mode values. Brand refreshes required manual find-and-replace across codebases. Design tokens lived in spreadsheets maintained by one person who was always on vacation. Most teams have a few stories like this.

Variables: from values to intent

Figma's Variables, first introduced at Config 2023 and expanded a lot through 2025, work differently. Instead of a color being a fixed value, it became a reference that could resolve differently depending on mode, theme, viewport, or any other contextual axis.

The big idea is aliasing. A semantic token like color/surface/danger can point to red/100 in light mode and red/900 in dark mode. The design intent lives in the variable itself. You don't need a separate document to explain the relationship, or a spreadsheet mapping "light danger background" to one hex and "dark danger background" to another.

Variable collections and scoping, refined significantly in Figma's 2025 updates, allowed teams to restrict where tokens could be applied. "Background" tokens only appear when you're filling a frame. "Text" tokens only show up when you're styling type. That removes a whole category of misapplication errors that used to surface only in code review, when a developer noticed someone had used a background color on text and the contrast ratio was unusable.

The idea isn't unique to Figma. It mirrors the design token specification from the W3C Design Tokens Community Group, which is gaining adoption across the industry. What Figma did was make it usable for designers who would never open a JSON file, turning an engineering abstraction into a visual workflow.

As a result, the Figma file itself became the source of truth, the actual system that designers and developers both reference, rather than a picture of it.

How Linear, Vercel and Notion rebuilt their color systems

The theory is tidy. The practice is messier, but three companies show how it can work.

Linear's design team has talked openly about using Figma variables to manage its famously restrained, multi-theme interface. Their approach has three tiers of tokens:

• Primitive tokens: raw color values like gray/900 or red/400
• Semantic tokens: contextual meanings like surface/danger or text/secondary
• Component tokens: specific bindings like button/danger/background

Figma variables handle the semantic-to-primitive mapping, and the codebase consumes the semantic layer directly through token export pipelines. Keeping the tiers separate makes theme switching easy instead of scary.

Vercel's design system, Geist, restructured its color architecture around variable collections that map directly to their CSS custom property system. The result is a near-1:1 relationship between what designers see in Figma's variable panel and what developers see in their stylesheets. When a designer applies --ds-gray-900, the developer sees the same token name in their code. At that point it's hardly a handoff. Both sides use the same names.

Notion's approach stands out for its scale. With a product that supports light mode, dark mode, and dozens of contextual color schemes (page covers, database views, callout blocks), they used variable modes to manage what was previously an unwieldy matrix of color assignments. Before variables, they needed custom tooling just to keep the system synchronized. Now the variable structure handles the combinations itself.

What the three have in common: the design system team's role shifted from "maintaining documentation" to "maintaining the variable architecture." The color page in Figma went from a reference sheet to an interactive, mode-switchable system that developers can inspect directly.

The end of the static style guide

The most visible casualty is the static style guide: the carefully maintained Notion page, the exported PDF, the Storybook color page that was always three sprints out of date. These are disappearing, and few people miss them.

When color relationships live in Figma's variable system and can be inspected in Dev Mode, you don't need a separate document to explain them. The design file is the system.

That changes onboarding. New designers joining a team no longer need to read a 40-page color guide. They open the file, see what tokens are available for a given property, and the scoping system prevents them from making invalid choices. The guardrails are built into the tool, not into a PDF that nobody reads past page 12.

It also changes the nature of design review. Instead of checking whether someone used the right hex code, reviewers check whether the correct semantic token was applied. That's a more useful question. It catches systemic issues ("you used a surface token for an interactive element") rather than superficial ones ("you used #0065FF instead of #0066FF").

Teams that have switched report something counterintuitive: with fewer documentation pages, new team members get up to speed faster. The system describes itself and has guardrails, so it teaches you what's valid as you work instead of asking you to memorize everything first.

Effects on design-to-code workflows

The change doesn't stop at design. It has shortened the whole handoff pipeline.

Token export pipelines, via tools like Tokens Studio, Specify, or Figma's own REST API and forthcoming token export features, now translate Figma variable collections directly into platform-specific code (CSS custom properties, Swift asset catalogs, Kotlin Compose theme objects) with little manual mapping.

Here's the old workflow:

1. Designer documents a color in the style guide
2. Designer writes a specification for a component
3. Developer interprets the specification
4. Developer creates a variable in code
5. Developer maps the variable to a component

And the new one:

1. Designer applies a variable in Figma
2. Pipeline exports the code-ready token

Five steps became two. That's a different process, not a tweak.

The "design technologist" or "design engineer" role has changed with it. They spend less time translating between Figma and code and more time designing the variable architecture and making sure the token naming works across web, iOS and Android.

Figma's Dev Mode, enhanced through 2025, now surfaces variable references rather than raw values in the inspect panel. A developer inspecting a button sees color/interactive/primary rather than #0066FF. The intent survives all the way from the designer to production CSS.

What's next: color that responds to context

Color in design systems is moving from a flat palette to a network of relationships that respond to context. "Danger" doesn't mean a specific red. It means a position in a semantic network that resolves based on theme, accessibility preferences, brand context, and potentially user personalization.

Figma's 2026 roadmap, based on community previews and beta features, hints at deeper integration between variables and conditional logic, with tokens that respond to accessibility settings or viewport conditions inside the design tool. If that ships, it means a designer could preview how their color system behaves for a user with low-vision preferences, without leaving Figma.

The convergence of Figma's variable system with the W3C Design Tokens specification, which is nearing maturity in 2026, could make tokens truly portable. Tokens defined in Figma could become a common interchange format that any platform or framework can read without proprietary translation layers.

That asks designers to think about color the way front-end engineers do, in terms of inheritance, cascading overrides and scope. For senior design system people, these skills are quickly becoming the baseline.

The teams that do well will treat their variable architecture as something to learn properly, not just a feature to switch on. Done well, it lets designers talk to developers about intent instead of hex codes.

The style guide page is gone, and that's fine

Moving from static color styles to contextual variable tokens changes how design intent gets from a designer to a user's screen.

The old handoff was a game of telephone. Intent was encoded as a hex code, documented in a style guide, interpreted by a developer, and re-encoded as a CSS value. Fidelity was lost at every step. The new model, used by Linear, Vercel, Notion and a growing number of other teams, removes most of that chain. You define a color relationship once and the system resolves it everywhere.

The style guide page in your Figma file might already be gone. If it is, it's worth learning how the thing that replaced it works.