DesignOps in action: automated token delivery from Figma to Drupal

Step 1: Organizing Variables

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.

Step 2: Exporting Tokens

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.

Custom plugin or any other plugin from the Figma community

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.

To automate token generation, we use a custom Node.js script. It takes exported Figma JSON tokens and converts them into CSS variables for each theme and component.

How it works

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.

Drupal Integration

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.

The release process ensures that every design and code update is consistent, traceable, and aligned across all brands.

1. Task created with design requirements.
2. Figma updated — a new component is added or an existing one is modified.
3. Tokens exported from Figma and imported into the Design System.
4. Developers implement a new component and assign the corresponding variables.
5. Review a new component in Storybook — verify the component and test accessibility.

   Once components are built, the pipeline runs automated accessibility tests. Tests cover color contrast, keyboard navigation, ARIA attributes, and other WCAG compliance rules. Any accessibility issues are flagged before merging or deployment.
6. Deploy the component to Drupal and configure any new backend fields if needed.
7. Test the component within the Drupal environment.
8. Deploy to production once approved.

Every change in this process is traceable, versioned, and consistent across all themes and environments.

This ensures that every change is not only visually consistent but also accessible, improving product quality and reducing manual testing effort.