Why Variants?
Design tools increasingly need to embrace concepts from both design and code, but every product team balances those considerations differently. Development relies on rigor and reusability to finalize and scale solutions, while design benefits from uninhibited freedom to iterate. Figma’s new Variants feature is an attempt to bridge that gap by changing how components are treated: it lets teams combine variations of the same component into a single asset, simplifying the asset panel and mapping components more closely to how developers think about them.
Before Variants, keeping a design system organized was tedious. Finding the right component and switching between related variations—through endless instance swap menus—didn't scale as companies grew. Many design system managers adopted a “forward-slash” naming convention (e.g. default/primary/large/icon) to work around Figma’s limits and communicate states and properties that were common in code.
Designing Around Real Workflows
To evolve components, Figma introduced support for multiple dimensions of variation using a key:value pair naming convention, like state="hover" or style="secondary". This lets components in Figma mirror components in code, whether the design system is simple and single-dimensional or complex and multi-dimensional.
Figma’s team arrived at the underlying architecture by shadowing design system managers. They observed that teams typically laid out component variations in a grid to compare and work on them side-by-side. The new feature is architected around that behavior: all variations of a single component can be laid out side-by-side on the canvas. This also created a simple path for adoption—select all component variations and click Combine Variants to turn them into one component set.
Refining the UI Through Usability Tests
After settling on component organization, the team ran four rounds of usability tests over six weeks to design an intuitive UI. One of the hardest challenges was communicating the new key:value naming construct. Initial designs showed all available property values as pills, but users struggled because pills are commonly understood as a way to tag an object with multiple attributes—an interaction that didn't match what they expected. After iteration, Figma simplified the design to a dropdown menu, only showing a simple input field for each property when a specific variant is selected. The pill design remains available when users want to see all properties and values of a component set at once.
Another learning came from default naming. Offering system defaults like State and Style was less intuitive than generic values such as “Property 1” and “Property 2”—the latter made it clearer that these should be customized to something like Type or Size.
Getting the Name Right
Deciding on the feature name was a significant part of the process. The project originally went by “States” because the initial use case was supporting interactive states such as hover, active, and disabled. But during testing, a user from Fidelity Investments pointed out that the name didn't capture the full scope: Variants can flex to any property type—type, color, size, and more. As the Fidelity team put it, “States seems to water down the power of the feature. It makes you think of just button or object states.”
Switching to “Variants” proved more representative, and subsequent usability tests confirmed the new name was more intuitive for the broader possibilities the feature supports.
Variants is available today to all users, alongside updates to Auto Layout and changes to the Inspect panel aimed at improving designer-developer collaboration. A walkthrough of the feature is available in the Figma community, with usage tips and best practices in the help center and Figma’s best-practices guide.
