Bridging design and code with Variants | Figma Blog (opens in new tab)

Figma’s Variants feature was created to bring component organization closer to how developers structure reusable code. It combines related component versions into component sets, supports multiple property dimensions, and simplifies switching between variations. The feature’s design was shaped through user research and usability testing, which refined both its interface and its name.

Bridging Design and Code

• Designers need freedom to iterate, while developers prioritize rigor, reuse, and scalability.
• Figma identified component management as a major opportunity to connect these workflows.
• Existing components were difficult to find, switch between, and organize, especially when systems contained many variations.
• Variants was designed to make design-system components resemble their code counterparts more closely.

Aligning Component Organization with Code

• Teams often used forward-slash names such as default/primary/large/icon to represent component states and properties.
• Variants replaced this workaround with key-value properties, such as:
  • state="hover"
  • style="secondary"
• The system supports both simple components and components with multiple dimensions, including state, type, color, and size.
• Research showed that design-system managers commonly arranged component variations in grids to compare and maintain them.
• Figma therefore allows all variations of a component to be displayed side by side.
• Existing component variations can be selected and converted into a component set using “Combine Variants.”

Refining the Interface Through Usability Testing

• Figma built a working prototype and conducted four rounds of usability testing over six weeks.
• The initial interface displayed all property values as pills, but users found this confusing because pills typically represent multiple tags or attributes.
• Figma changed the interaction to:
  • Use dropdowns and simple input fields when editing a selected variant.
  • Retain pills when viewing all properties and values in a component set.
• Generic default labels such as “Property 1” and “Property 2” proved clearer than predefined labels like “State” and “Style,” because users understood they should customize them.

Choosing the Name “Variants”

• The feature was initially called “States,” reflecting its early focus on interactive states such as hover, active, and disabled.
• User feedback showed that “States” understated the feature’s broader capabilities.
• Variants can represent any component property, including type, color, and size—not just interaction states.
• Testing confirmed that “Variants” better communicated the feature’s flexibility and scope.

Variants, combined with updates to Auto Layout and the Inspect panel, is intended to make design systems easier to organize and easier for developers to interpret. Teams should use component properties and sets to model reusable UI elements in a way that matches both design workflows and code structures.