Skip to content

CONCEPT Cited by 1 source

Parameter system

A parameter system defines values that can be set once and applied across many consumers. Change the value in one place → all consumers update. The consumers are usually properties on objects in a document; the parameter is a named typed value the properties read from instead of storing directly.

Figma's 2026 unification retrospective (Source: sources/2026-04-21-figma-parameter-architecture-unification) names the shape explicitly and identifies two axes that distinguish instances:

Two axes

1. Source-of-truth location (scope)

  • Scoped parametrization — parameters defined on a specific object (e.g. a component) and restricted to consumers inside that object. Figma's component properties (2022) sit here: each property lives on a component or instance layer and can bind only to layer properties inside that component set. The scope acts as a customization contract — downstream users of the component can customize only what the author exposed.

  • Global parametrization — parameters defined at a library or document level and available to any consumer with access to the library. Figma's variables (2023) sit here: a color variable in a design system library binds to any layer in any file that has access to the library.

These are not different data models — they're different residence rules for the same underlying primitive.

2. Parameter value-type space

The set of types a parameter can take (boolean, string, number, color, …). In Figma's pre-unification world, component-property types and variable types were parallel definitions — ComponentPropType.BOOLEAN vs VariableType.BOOLEAN as distinct types. This is the accidental- complexity trap: adding a new type requires implementing it twice, and cross-system bindings are impossible because the types don't match.

A unified typespace — a single source of truth for boolean, number, color, … that every parameter system references — is the pre-condition for (a) cross-system bindings (bind a component property to a variable) and (b) low marginal cost for adding a third parameter system later.

Four runtime stages

Every parameter system, regardless of axis choices, runs a four-stage pipeline per change:

  1. Parameter usage tracking — maintain a reverse index parameter → {bound layer properties} at property granularity.
  2. Invalidation — on any of {parameter value changed, binding changed, mode switched}, gather the affected properties.
  3. Resolution — recompute each affected property's value, which may involve a multi-hop walk (concepts/transitive-parameter-resolution) including across parameter-system boundaries.
  4. Updates — re-render layers with the new resolved values.

Before Figma's unification, each system implemented all four stages separately; after, all systems share one pipeline and any new system inherits it.

Compared to sibling primitives

  • Styles (Figma, 2018) are parametrized bundles of values (e.g. a text style = font-family + size + weight applied together). Styles pre-dated variables and lacked granular parametrization — you couldn't parametrize the font size independently. The parameter-system abstraction subsumes them: variables give granular control, styles give bundled application.
  • Reactive frameworks (React state, MobX observables, Svelte stores) have the same set-once-apply-across shape at the application-framework level. Parameter systems are the document-model analogue — the reactive graph is part of the persisted document schema, not just the UI layer.

Seen in

Last updated · 200 distilled / 1,178 read