Variable Modes

Variable modes are sets of alternative values inside one Figma collection that let you flip themes without copying tokens everywhere. Light dark and brand variants live here as different resolutions for the same semantic names. The concept exists to stop teams from creating separate collections for every variation which quickly turns into maintenance hell.

It is not a new collection for every theme. It is not manually changing values on every layer. The biggest confusion comes from treating modes like folders. Teams create light collection and dark collection then wonder why their export pipeline explodes. Modes are variations within one concern. Collections separate entirely different concerns like color versus spacing.

The article decision tree makes it clear. Light and dark belong as modes inside the color collection. Compact versus comfortable spacing gets modes inside the spacing collection. Brand variations live as modes in the semantic layer. Break this rule and you are one rebrand away from manual find and replace across hundreds of frames.

Look at how Stripe handled their 2023 dark mode launch. They added a dark mode to their existing semantic collection. The primitive blue 500 stayed exactly the same hex. The semantic text link token simply pointed to a different primitive in dark mode. Component tokens above it updated automatically. Zero component layers needed editing. That is modes done right.

Atlassian uses modes for locale as well. Their string variables switch between English and Arabic layouts with one mode toggle. The layout reflow happens in real time inside Figma. Developers receive the exact same boolean and string variables as props in code. The gap between design and production shrinks to nearly nothing.

Deploy variable modes when your product needs theming or multiple densities. Avoid them on static brand assets or single mode prototypes where the complexity adds noise instead of value. The tradeoff is cleaner organization against a steeper learning curve for junior designers who just want to pick a color.

Primitive layers never get modes. That is a category error. Primitives stay raw and constant. Only semantic tokens carry the mode aware meaning. Everything above semantic stays mode agnostic. Everything below stays meaning agnostic. Get this distinction wrong and your audit will light up red.

The article audit checklist catches mode mistakes immediately. Light and dark must be modes not collections. Brand variants must be modes not separate files. Primitive collections must have zero modes. Fail more than three checklist items and the system needs a full rebuild not a patch.

Figma variables shine brightest when modes are used correctly. The panel finally becomes a single source of truth instead of a better styles panel. Teams that master modes cut their design system debt in half according to the internal audits at companies running this exact setup.

Stop creating new collections every time something changes. Modes exist to handle variation within a concern. Use them that way and your token system survives production instead of becoming the next redesign project.

A well built mode system turns theme requests from engineering tickets into configuration updates. That single shift is worth the entire architecture conversation.