Separate a value, a context, and a component configuration
Figma variables store reusable values, collections organize variables, and modes provide alternative values for a context. Component variants organize related component configurations. These concepts work together, but they answer different design questions.
For an illustrative SaaS settings screen, the surface color is a reusable value, light or dark is a theme context, and a button's enabled or disabled configuration is a component state. Write those meanings down before creating a large set of combinations.
| Design question | Candidate Figma concept | Example |
|---|---|---|
| Which reusable value should this layer use? | Variable | color/text/primary |
| Which context supplies its value? | Collection mode | Light or Dark |
| Which component configuration is shown? | Variant property | State: default or disabled |
| Which product meaning should stay stable? | Semantic naming agreement | Primary action versus destructive action |
Name colors by their job before applying themes
Choose a few semantic roles such as background surface, primary text, muted text, border, and primary action. Give each role a value in each theme. Figma supports aliasing a variable to another variable of the same type, which can connect semantic roles to a palette.
For the settings example, avoid naming a functional role white if it needs to become dark in another context. A role such as surface/default explains why a layer uses the color. Keep a small mapping that a developer can connect to the implementation's existing token names instead of inventing two unrelated naming systems.
Apply modes and inspect inheritance
Figma lets you set variable modes on objects and pages, with Auto inheriting context through parent containers. Explicitly selected modes can behave differently from inherited defaults. Check the parent and child settings when part of a screen refuses to switch with the rest.
Apply the semantic variables to one settings form, then switch its container between light and dark. Inspect nested components and overlays as well as the main frame. A component that looks correct by itself may have an explicit mode that prevents it following the context where the team uses it.
Keep variants focused on useful component choices
Figma variants use named properties and values to describe component configurations, and each variant needs a unique combination. The documentation also cautions that large component sets affect performance. Create the combinations the product actually needs rather than expanding every theoretical permutation.
For the sample button, begin with the supported sizes, intents, and states. If light and dark differ only in token values, modes can supply those colors. If a configuration changes structure, such as adding a loading indicator, decide how that behavior belongs in the component model. Do not create a theme variant merely because a color changed.
Test states in the context where customers encounter them
Review default, focused, disabled, error, and loading experiences as relevant to the actual component. Place them on the real surface colors used by the screen. Check text and controls with appropriate contrast evaluation rather than assuming that a successful theme switch establishes accessibility.
In the settings screen, examine a failed save and a disabled submit action. Their meanings should remain understandable in both themes. Include an example with longer text so that the design review also catches a label wrapping into a neighboring element. The system needs to survive real content, not only the shortest labels.
Hand off the mapping and its limitations
Share the semantic names, theme values, and supported component states with the implementation owner. Record which choices are part of the product contract and which are still exploratory. A design mode does not automatically implement runtime theming, persistence, or the application's accessibility behavior.
Expand the library after another screen can reuse the first set without copying values or inventing exceptions. Figma is useful for this workflow when the variables and component model make a design change understandable to the whole team. A smaller, coherent system is easier to maintain than an exhaustive collection with unclear ownership.
Sources and editorial method
Official sources linked in this guide were checked on October 27, 2026. Product features, interfaces, and plan limits can change. The examples are proposed workflows, not reports of a hands-on benchmark or customer results. Confirm the documentation for your product version before implementing a workflow.