A Tale of Two Parameter Architectures—and How We Unified Them | Figma Blog (opens in new tab)

Figma’s component properties and variables both let users define a value once and apply it across a design, but they were originally built on separate architectures. This led to conflicting bindings, inconsistent rendering, and duplicated engineering effort. Figma unified the systems into one parameter architecture, improving consistency and creating a scalable foundation for future products.

Two Different Parameter Systems

• Component properties, introduced in 2022, addressed the gap between design and code.
• They enabled scoped parametrization: parameters could be defined by a component and applied only to its internal layers.
• This gave design-system authors a clear customization contract and mirrored how component properties work in code.
• The model supported features such as:
  • Boolean properties
  • Text and instance customization
  • Component variants and states
• Component properties helped power products including Figma Sites, Figma Make, and Code Connect.

Variables and Global Parametrization

• Variables provided a broader, more globally reusable parameter system.
• They supported values such as colors and could define different values for contextual modes, such as light and dark themes.
• Unlike component properties, variables were designed to be reused across many unrelated layers and components.
• This made variables well suited to design tokens and system-wide configuration.

Problems Caused by Separate Architectures

• The two systems evolved independently despite having similar goals.
• A variable and a component property could bind to the same layer property, producing inconsistent results in the editor.
• Users had to learn different behaviors and rules for concepts that appeared similar.
• Maintaining two implementations increased engineering complexity and slowed feature development.
• Extending parametrization to other Figma products risked reproducing the same technical limitations.

Unifying the Architecture

• Figma built a single underlying parameter architecture to support both component properties and variables.
• The unified system preserves the distinction between:
  • Parameters scoped to a component
  • Parameters reused globally across a project
• It eliminates competing bindings and makes parameter behavior more predictable.
• The change also improves developer velocity by allowing new capabilities to build on shared infrastructure.

Broader Impact

• Designers receive a more consistent mental model for configuring components and design systems.
• Rendering behavior is more reliable when multiple parameter types interact.
• Figma can extend parametrization across existing and future products without maintaining separate technical foundations.
• The unified architecture supports Figma’s broader goal of connecting design-system behavior with code and interactive products.

Figma’s recommendation in practice is to treat component properties and variables as complementary uses of one parameter model: use scoped properties for component contracts and variables for reusable, contextual design tokens.