Summary

Add support for "global" or "parent" mode dimensions that apply across multiple variable collections. This would allow a theme like light/dark to act as a global setting that affects all other collections (like Surface, Density, or Brand) without needing to manually create every combination.

The Problem

Currently, Figma treats each collection's modes as independent and flat. When building a design system that needs both a theme (light/dark) and a surface context (default/prominent/muted), there's no way to express that light/dark should be a global setting that applies across all surface contexts.

Current Workaround

We're forced to combine both dimensions into a single collection with combined mode names:

Collection: Surface
Modes:
  - default/light
  - default/dark
  - prominent/light
  - prominent/dark
  - muted/light
  - muted/dark

This leads to:

• Combinatorial explosion: Adding one surface means adding two modes. Adding one theme means duplicating all surfaces.
• Maintenance burden: A system with 4 surfaces × 2 themes = 8 modes. Add a third theme (high contrast) and it becomes 12 modes. Add density (compact/comfortable) as another collection with the same problem and complexity multiplies further.
• Misaligned mental model: Designers think of light/dark as a global switch, not as something to manually pair with every other mode.

Proposed Solution

Introduce mode dimensions or hierarchical modes — a way to define certain modes as global settings that overlay other collections.

Concept: Global Mode Dimension

Global Dimensions:
  Theme: light | dark | high-contrast

Collections:
  Surface:
    Modes: default | prominent | muted

  Density:
    Modes: compact | comfortable

When a frame is set to:

• Theme: dark
• Surface: prominent
• Density: compact

All tokens resolve through all three settings simultaneously. The system handles the combinations internally, without requiring designers to create every permutation as an explicit mode.

Where to define values: Tokens would still need values for each combination — that's unavoidable and expected. For example, button/background would have a value for default + light, default + dark, prominent + light, etc. The difference is that these combinations would be defined within the token's value table, not as separate modes cluttering the collection's mode switcher. You'd see a grid or matrix of values rather than a flat list of combined modes.

Alternative Concept: Parent/Child Collections

Allow collections to "inherit" or "subscribe to" a parent collection's mode:

Collection: Theme (global: true)
  Modes: light | dark

Collection: Surface (inherits: Theme)
  Modes: default | prominent | muted

  Token: button/background
    Values:
      default + light: {blue-500}
      default + dark: {blue-400}
      prominent + light: {white}
      prominent + dark: {neutral-100}

The inheritance relationship means Surface always resolves within the context of whatever Theme mode is active on the frame or its ancestors.

Benefits

1. Scales gracefully: Define n + m + o modes instead of n × m × o combinations
2. Matches mental model: Designers already think of light/dark as a global toggle
3. Reduces errors: No risk of forgetting to update one combined mode when changing a value
4. Cleaner organization: Collections stay focused on their specific concern (surface, density, brand) without being polluted by theme variations
5. Simpler prototyping: "Switch to dark mode" becomes one action affecting the whole prototype, not updating multiple modes across different frames

Use Cases

Multi-surface design systems

Design systems with surfaces like default, prominent, muted, elevated, inverse — each needing to work in both light and dark themes.

Multi-brand systems

Agencies or companies managing multiple brands that each need light/dark variants. Currently requires: brand-a/light, brand-a/dark, brand-b/light, brand-b/dark, etc.

Responsive density

Systems offering compact/comfortable/spacious density modes that should each work across all theme and surface combinations.

Accessibility themes

Adding high-contrast or reduced-motion modes that should apply globally without multiplying every existing mode.

Current Impact

Many design systems are either:

1. Avoiding the problem by keeping surfaces minimal (losing expressiveness)
2. Accepting the maintenance burden of managing many combined modes
3. Splitting logic unnaturally to keep mode counts down
4. Using external tools like Tokens Studio to manage the complexity, then syncing to Figma (added friction)

A native solution would significantly improve the variables feature for any team building a non-trivial design system.

Summary

The core request: let us define light/dark (or any theme) as a dimension that applies across all other collections, rather than requiring us to manually create every combination as a separate mode. This would make Figma's variables system match how designers actually think about theming.

Thank you for considering this! ❤