Want to learn how to better scale your design systems within Figma? Join Luis to learn about a new feature that they are releasing very soon. We'll look at the why, how, what, and where of the future design system state within Figma. Bring your notebook!
Watch this WaysConf session, then continue with related talks or explore the current programme.
Figma variables introduce a structured layer for reusable values such as color, spacing, and future design properties, but their value depends on careful system architecture and migration. The talk explains collections, primitive and semantic layers, component-specific aliases, modes, and gradual adoption. Rather than replacing styles or demanding an immediate rewrite, variables can reduce maintenance and support themes, brands, and products when teams establish naming, ownership, deprecation, and communication practices before scaling.
Variables are reusable values inside files, and teams need a clear collection and naming structure before applying them across components.
Watch from 1:02Raw values should live beneath semantic aliases so components depend on purpose-based names rather than fixed colors or measurements.
Watch from 3:32Specific component tokens can make state and maintenance decisions explicit without duplicating the central value library.
Watch from 6:22Adoption should match team capacity and system complexity instead of forcing every style and component to change at once.
Watch from 12:06Deleting or relocating a variable can affect many files, so teams need ownership, notices, and migration support for consumers.
Watch from 18:14These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.
Variables live in Figma files alongside components and styles, but they should not be treated as a purely visual feature. Once a team distributes them, each value becomes a dependency. Collections, names, scopes, and owners therefore matter from the start, even if the first implementation contains only a modest set of colors or spacing values.
Watch from 1:02A primitive library stores the basic palette and measurements, while semantic variables explain why a value is used. Components can then point to semantic or component-specific aliases. This separation lets a central value change without requiring designers to edit every instance, and it keeps interface decisions understandable beyond a color code.
Watch from 3:32Component-level variables can describe exact purposes such as an error-alert background or a button state. The extra specificity should solve a maintenance problem, not become bureaucracy for its own sake. A team can stay broad at first, then add narrower aliases where repeated variants, themes, or product differences make the benefit clear.
Watch from 6:22A design system does not need to move from styles to perfect variable coverage in one release. Teams can introduce a central collection, connect a limited group of semantics, migrate high-value components, and observe where complexity appears. This sequence protects delivery while giving the system time to reveal the architecture it actually needs.
Watch from 12:06A deleted variable or style may break themes and files far from the library where the decision was made. Deprecation therefore needs the same care as a public interface change: identify consumers, announce the replacement, provide a migration path, and allow enough time for teams to move before the legacy value disappears.
Watch from 18:14
