DesignOps in action: automated token delivery from Figma to Drupal

We implemented Figma Variables for each component, enabling efficient design system tokenization and grouping them into structured collections.

• Primitives — the foundation of all design decisions.

  Includes fixed raw values such as grid, spacing, colors, typography, and stroke.

  If the project is large and involves multiple designers, this collection can be separated into its own Figma Library to ensure consistency and prevent accidental changes.

• Colors — all the colors used in our Design System.
• Theme — contains color-related variables for light and dark modes.
• Dimensions — include paddings, margins, breakpoints, and other responsive spacing values, each having breakpoints as modes.

All component-level variables are linked to the Primitives and Colors collections, ensuring a single source of truth across the design system.

We developed a Figma Token Export Plugin that exports design system tokens (variable collections) into structured JSON files. However, any free plugin from the Figma Community can work as well.

Each collection generates a dedicated export file. For example:

• primitives.json — base variables
• dimensions.json — shared component variables with responsive breakpoints
• ⁢theme.json — shared variables with light/dark modes

Inside the exported JSONs, each token is represented as a structured object containing collections, value types, and aliases.

As of December 2025, Figma introduced a native feature that allows importing design tokens directly into Figma Design. To do that, design tokens must be in a JSON file and follow the DTCG format. Figma also supports exporting variables back into a JSON file, making it easier to maintain a two-way workflow between design and development.

Each brand is represented as a mode, and the entire system lives in a single Figma file. This approach has its pros and cons.

Pros:

• One export covers all Drupal themes.

Cons:

• Figma currently supports ten modes, which limits scalability for large design ecosystems.
• Additionally, managing light and dark modes with multiple brand modes within a single Figma file can be complicated, because multiple brands and themes need to coexist.

Each brand has its own Figma file, linked to a Core Design System library.

Every file exports its own JSON file with Figma tokens.

The Core Design System file contains:

• All Primitives and basic collections
• All Component Variables

In this setup, each Drupal theme has its own JSON file acting as an override layer:

• If a value exists in the brand file, it overrides the core default.
• If not, the core value is used.

This structure keeps brand-specific customization clean and maintainable.

The script reads all token files from the /tokens directory of each theme, processes them, and outputs generated .scss files with correctly formatted variables, responsive breakpoints, and light/dark mode selectors.

Here’s what it does step by step:

1. Imports core dependencies and prepares configuration
2. Defines helpers for naming and formatting:
   • converts token references (e.g., ‘core/colors/red/600’) into valid CSS references (var(--colors-red-600)).
   • Automatically converts px values to rem.

3. Generates CSS variables

   Recursively processes each JSON object to produce valid CSS variable declarations:

   --components-button-primary-bg: var(--core-colors-red-600);

4. Wraps variables with proper selectors such as :root, .dark, or @media queries for responsive values:

   :root {
    --color-text: #111;
   }
   @media (min-width: 768px) {
    :root {
      --core-spacing-md: 1rem;
    }
   }

5. Handles theme-specific logic and writes output files

All SCSS files are compiled into a git-ignored directory containing the generated CSS variables. Each component gets its own file, which includes responsive breakpoints and light/dark mode variables.

Collections such as Typography and Core are built as separate SCSS files, one per collection.

Example of auto-generated badge-vars.scss

All these files are imported automatically during the webpack build. We only need a single import inside the Global Design System — no manual setup per theme.

We also added a frontend variable layer with simplified variable names. This allows us to override variables in any component and control them directly in code.

If a Figma variable name changes (rare but possible), we only need to update it once, where the default value is defined.

We recommend defining variables at the root level, which allows them to be overridden from anywhere. However, naming consistency is key.

To reduce CSS size in production builds, we shorten variable names using a structured system:

…and similar naming rules for other elements.

All generated CSS variables are automatically included in each Drupal theme.

This allows us to control theming purely via tokens, eliminating the need for manual CSS edits.

We use the SDC Drupal module with a custom path configuration. It automatically loads CSS and JS from the /dist folder of each brand theme. The module dynamically resolves paths relative to the active theme directory, and CSS for a component is included only if that component is used.

Designers and developers can manually export variable collections from Figma using the Token Export Plugin.

This approach is useful for testing, quick updates, or reviewing design changes before they go live.

In this case, the exported JSON files need to be stored in the Git repository to ensure that all changes are tracked and remain consistent across environments.

In this workflow, most steps run automatically through the Figma plugin integration:

1. A designer updates or adds a component in Figma.
2. The Token Export Plugin sends updated variables to the Design System repository.
3. A Pull Request is created automatically with the new token files and assigns a reviewer.
4. Changes are reviewed in Storybook and merged into the release branch.
5. During the next deployment, the system builds updated CSS variables for all themes.

This workflow provides automation while maintaining full transparency and control over reviews.

In this fully automated scenario, Drupal requests data directly from Figma’s API.
When triggered, Drupal calls the Figma endpoint and retrieves the latest design tokens automatically.

In this setup, tokens are stored and managed on the Drupal side, without the need for manual export or versioned JSON files.

Note: The Figma API is available only on Enterprise plans.

This end-to-end automated pipeline ensures that design and code are always synchronized with minimal manual effort and full version control.