Design systems move from components to meaning

Figma's recent introduction of Variables has sparked conversation among design teams about what comes next for design systems. The feature itself—which allows designers to store and reuse values like colors, spacing, and typography—is practical, but it also points to a deeper shift in how design systems are being conceived and built.

For years, design systems have been component-centric. Teams build libraries of buttons, inputs, cards, and other UI elements, then document how they should be used. This approach works, but it has limitations. Components are concrete and inflexible: a button component with a specific set of properties can only be used in so many ways before you end up with a bloated library full of variants and exceptions.

Variables take a different approach. Instead of defining a specific color as "primary button background," you define it semantically—say, as a token for "primary action." The value can then be referenced across any number of components, themes, or contexts. The same variable might map to one value in a light theme and another in a dark theme, or to different values in different product areas.

What semantic design actually means

This shift from concrete to semantic is not just a Figma feature trend; it reflects a broader movement in design and engineering. In code, design tokens have long been used to bridge the gap between design decisions and implementation. Tools like Style Dictionary have made tokens a standard part of modern front-end workflows. Figma's Variables bring this same idea directly into the design canvas, allowing designers to work with the same abstractions that engineers use.

Semantic design means naming things for their role, not their appearance. A color token might be called surface/raised rather than light-gray-100. A spacing token might be space/sm rather than 8px. The benefit is flexibility: when the underlying value changes, the system updates everywhere that references it. When a new theme or brand is introduced, the semantic layer stays consistent even as the raw values change.

The practical impact on design workflows

For design teams, the practical payoff is in theming and collaboration. Variables make it possible to swap color schemes or spacing scales without manually hunting through documents for each instance. Design systems can be structured so that changing a brand color or adding a dark mode is a matter of updating token values, not refactoring components.

There are also implications for handoff. When design files contain semantic names that match code-level tokens, the translation from design to implementation becomes quieter and less error-prone. Developers no longer need to infer what a color or spacing value is for; the intent is already encoded in the name.

Beyond variables: where the industry is heading

Variables are only one signal. Other trends—such as increased adoption of design tokens in developer tooling, more sophisticated theme management, and growing interest in cross-platform consistency—all point in the same direction. Design systems are becoming less about isolated component libraries and more about a shared semantic foundation that can be applied across products, platforms, and contexts.

The long-term implication is that design and engineering teams will increasingly align around a common vocabulary. Components will still matter, but they will be powered by semantic layers that define meaning ahead of appearance. As this shift continues, designers who think in terms of systems rather than screens—and in terms of roles rather than style—will be better equipped for what comes next.

Design Tokens Evolve Into Something More Flexible

For design systems practitioners, few announcements at Figma’s Config 2023 carried more weight than the introduction of variables. At Framework 2024, the company extended the feature set with Code Connect for developers, typography and gradient variables, and a Library Analytics API intended to help organizations track design system adoption.

Variables store reusable values that can be applied across design properties and prototyping actions. But they are not merely a Figma equivalent of design tokens: their defining characteristic is that they can vary. Where tokens codify a single decision, variables and modes let teams swap designs between different contexts—light and dark themes, languages, screen sizes—and reference other variables so that updating a shared value propagates everywhere it is used.

“In my mind, variables is a much broader concept, and tokens are one flavor of that,” says Lauren LoPrete, who beta-tested the feature with her design systems team at Dropbox. Beyond token management, LoPrete sees utility in localization workflows, where variables can represent strings in multiple languages, and in empowering non-systems teams to prototype independently without breaking established patterns.

From Hundreds of Colors to a Manageable Set

Design tokens emerged around 2014, with Salesforce widely credited as the pioneer. They address a familiar problem: when a product matures, its design decisions multiply. A team at Google Maps tackling a palette cleanup found more than 700 colors in use; after a year of work, they reduced that to 25 hues.

Tokens keep such systems from regressing by storing small, repeatable decisions—colors, spacing, radii, type—as data that can be referenced across platforms and components. A single change updates everywhere a token is used, reducing redundancy across products.

“The new color system helps our users better understand the world around them, while aligning it to the Google palette sets us apart and builds brand equity,” says Sang Han, Director of UX at Google. “Because the system is easier to update, it also positions our team to keep moving the brand forward.”

Bridging Design and Development

Variables double as communication tools between design and code. Figma’s REST API offers read and write access for variables, and the Plugin API supports querying, creating, deleting, and binding them to components. Community builders have already used variables in prototyping to create functional versions of games like Flappy Bird and Jeopardy.

Prototyping is where the design-code gap narrows most visibly. Variable values can be modified through prototyping actions, letting designers build interactive prototypes that respond to user input—combining expressions that generate dynamic strings, evaluate booleans, or perform arithmetic—without writing code.

“One of our design team’s principles is to empower creativity through flexibility,” says LoPrete. “Before variables, our system was so rigid that consumers weren’t able to manipulate it in a way that wouldn’t break the system completely.” She cites a case in which her team used variables to give their Growth group a playground for A/B testing call-to-action and pop-up colors.

This shift also reduces ongoing maintenance. “I’m excited to see a big reduction in the amount of overhead that those managing design systems will need to deal with,” says Tom Lowry, Design Advocate Manager at Figma. Designers can work in their preferred mode—light or dark—and toggle to see alternatives instead of managing complex multi-library setups or component variants for each color mode.

As design and development tools converge, the traditional handoff is becoming less meaningful. “It still feels like there’s a fence that you throw your work over and an engineer picks it up on the other side,” LoPrete says. “I’d like to see that get to a place where it’s a much more collaborative or shared process.”

Broadening Participation Beyond Design Systems Teams

The interface around variables makes what was historically a developer concept approachable to more contributors. “It’s not exclusive to design systems people working on design systems,” Lowry says. “We’ve expanded the utility to where a content designer can come in and define terminology.”

LoPrete argues that maintenance and evolution of a system require different skills than its initial creation. Her Dropbox team includes technologists who prototype and build components in React, designers focused on community and collaboration models, and operations staff managing adoption and feedback loops.

What Comes Next

The stated roadmap for variables extends well beyond current support. “Any design decision that can be reused could be a variable, whether or not that fits in the scope of design tokens,” Lowry says. He points to potential applications in content libraries, where teams could review terminology and calls to action in one place, and in animation, where easing curves might vary by context such as alerts versus transaction confirmations.

“Could you use variables within other variables? Could you create expressions that make a calculation based on variables for a value?...There are so many ways that variables could help us create more complex, more dynamic designs,” Lowry adds. “This is the start. We’re not done.”

Some practitioners expect the systems themselves to become less visible over time. “I see documentation websites diminishing, as more products like Figma that incorporate design systems provide that natively within the app,” says Nathan Curtis, design systems architect and founder of EightShapes. Systems-oriented documentation may increasingly live inside tools, so users don’t leave the app to learn how to make the right decision.

Automation could also change the nature of such work. Curtis notes that much of what he does follows repeating patterns. “I’ve designed token taxonomies, what, 30 or 40 times and they all tend to have an action-color group and an alert-color group,” he says. “From that perspective, I don’t anticipate many people paying me to do token taxonomies five years from now.”

Semantic layers in practice

Shifting a design system to semantic tokens is not just a rename exercise. It requires a clear separation between the raw values—like a hex code or a pixel size—and the roles those values play in the UI. The raw layer stays stable, while the semantic layer adapts to context, theme, or state.

Consider a button. Its background color might reference a token like color.bg.action rather than a fixed palette entry. The same token can then resolve differently on a dark theme or in a disabled state without touching the component code. This indirection is what makes large-scale theming and cross-platform consistency practical.

For teams adopting this model, the practical workflow involves a few key steps:

  • Audit existing components and map every hard-coded value to a raw token.
  • Define semantic roles based on function—surface, text, border, action, and so on—rather than on color names.
  • Keep the semantic layer thin; over-nesting tokens quickly becomes unmanageable.
  • Automate the export of tokens into platform-specific formats so that everyone consumes the same source of truth.

Tooling catches up

Design tools are beginning to treat tokens as first-class objects, not as add-ons. Modern workflows let you store token values centrally and reference them across files, which bridges the gap between design and code. The payoff appears in handoff: what a developer receives is already structured as named variables, not ambiguously named layers.

Versioning and communication also improve. When a token changes, the update propagates everywhere it is referenced, eliminating the manual hunt for instances. The design system becomes a live contract rather than a static document.

Long-term maintenance advantage

The real benefit of semantic tokens emerges during evolution. Rebranding, adding a dark mode, or supporting an accessibility forced-colors mode all become scoped updates at the token level. You can change the value of a role and let the system handle the fallout. That reduces risk and speeds up delivery.

Teams keep their design systems durable by rejecting visual naming early and pushing semantic roles into the language everyone speaks—both designers and engineers. The most robust systems are not the ones with the most tokens, but the ones where each token name carries meaning that outlasts a single design trend.