At Domino’s, we strive for consistency and scalability when building UIs across web and mobile platforms. While we have always aimed for a unified design and development process, maintaining consistency in design variables across projects has been challenging. With the introduction of Figma’s Variables API, we are addressing this issue by automating the fetching of Figma variables directly into our codebase, which enables us to maintain consistency between design and UI implementation and support both light and dark modes seamlessly.

In this post, I will walk you through how we are beginning to leverage Figma’s API to automatically generate design tokens, improving our workflow by aligning design and development more closely.

The Problem We Had To Solve

At Domino’s, the web and mobile apps teams use Figma as the single source of truth for UI design. This includes designs for mobile apps, our e-commerce website, email templates, and more.

When developing UI, developers must ensure that no raw design values (like the HEX values of colours) are used across the code, following the “DRY” (Don’t Repeat Yourself) principles to maintain clean codebases across all projects.

Developers achieve this by converting reusable design values found in designs, like colours and sizes, into variables in our codebase. Then, those variables can be used anywhere in the code, ensuring consistency in the codebase and produced UI.

The Challenge of Consistency

Maintaining consistency between the naming conventions of those variables has been quite a challenge, though. Many of Domino’s projects – whether it is our Vue.js UI components library (known as Shared), email templates, or mobile apps — were built over many years by different teams, often in isolation, and they all now maintain their own sets of design variables, which causes unnecessary complexity and inconsistencies between codebases.

For instance, here is an example of one colour which is named differently across different projects:

This scenario becomes particularly problematic when scaling up and adding new projects. Adding new sets of design variables to new projects is neither ideal nor scalable, leading to friction and inefficiencies.

Introducing Design Tokens

To address this issue, we began working towards adopting design tokens.

Design tokens are a centralised set of design values like colours, fonts, and shadows that are common across all projects. These values can be packaged into a single resource and shared across the organisation.

Essentially, design tokens allow you to go from this setup for multiple projects:

To this:

With design tokens, we can ensure consistency across all projects and simplify the process of maintaining design values. Any updates made in Figma can be instantly reflected in the codebase via the token generation process, ensuring that design and development stay in sync.

Leveraging Figma’s Variables API

We can achieve design tokens in a couple of ways. For example, some teams maintain files containing all design tokens in an easy-to-access location, and then these files are used as a single source of truth by everyone - devs and designers.

This approach is better than maintaining multiple sets of design values. However, it is still very manual - someone needs to update the files whenever changes are introduced.

For us, a more scalable approach is to fetch design tokens directly from Figma via the recently introduced Variables REST API.

Figma’s Variables API provides direct access to the variables our designers create in Figma files, allowing us to automate the design token generation process.

Once the design tokens are generated, we can then utilise them across multiple projects, ensuring not only consistency in the developed UI but also in naming conventions.

How Figma’s Variables Simplify Theme Support

One of the most powerful features of Figma variables is their ability to support multiple themes—such as light and dark modes—by centralising the definitions for colour and other design properties. In Figma, you can define a single variable, such as background-color, and assign it multiple values depending on the theme. For example:

• background-colour for light mode: #ffffff
• background-colour for dark mode: #000000

Instead of duplicating these values in different places, Figma variables allow you to manage them in one location, ensuring that theme-specific styles are consistent and easy to update.

This setup also simplifies the front-end implementation of themes. When Figma variables are fetched and converted into CSS variables, switching between light and dark modes becomes as simple as toggling between different sets of predefined tokens. This not only makes it easier for developers to implement themes but also ensures consistency across different projects.

By having design tokens stored in Figma and accessible via the API, any updates or changes made by the design team—such as altering a colour or introducing a new theme—will be reflected across all projects using these tokens. This will eliminate the need for manual updates and ensure that both the design and development teams remain in sync.

Automating the Fetching of Design Tokens

Before we could even think about automating the generation of design tokens, our design team had to create a comprehensive design system in Figma containing variables supporting light and dark modes.

This was a lengthy process, as they also had to update all designs with the new variables. However, once that was completed, the UI team's task was straightforward: we built a Node.js application to fetch and process those variables into design tokens in the required format for our initial application.

We chose Node.js for this task for several reasons:

1. JavaScript Ecosystem: Node.js allows us to use JavaScript on the server-side, which aligns well with our front-end development stack. This means our front-end developers can easily understand and maintain the token generation script.
2. Rich Package Ecosystem: npm (Node Package Manager) provides access to a vast array of open-source libraries, including those specifically designed for interacting with APIs and processing data.
3. Asynchronous Processing: Node.js's event-driven, non-blocking I/O model is well-suited for making API calls and processing the responses efficiently.
4. Cross-platform Compatibility: Node.js runs on various operating systems, ensuring that our token generation process works consistently across different development environments.

Here's how the setup works:

1. Authentication and Setup: First, we set up Figma API access by generating a personal access token and obtaining the ID of the file containing all design tokens. A personal access token is a unique identifier that allows our application to securely access the Figma API. It can be generated in the Figma account settings.
2. Fetching Data: Once authenticated, our Node.js script fetches the published variables data from Figma.
3. Processing Data: The data is then processed, and we generate separate files for different token collections (e.g., Core colour tokens and Light/Dark mode tokens).
4. Generating CSS Variables: Finally, we generate design tokens as CSS variables for our web projects. These are grouped into SCSS mixins for light and dark modes. For example, we might generate tokens like this:

/* Tokens for light mode - CSS variables */
@mixin modes--light--css-vars {
  --text-primary: rgba(57, 51, 54, 1); 
  --text-secondary: rgba(84, 84, 84, 1); 
  --text-black: rgba(57, 51, 54, 1); 
  --text-brand-blue-default: rgba(0, 100, 145, 1); 
  --text-brand-blue-bold: rgba(0, 100, 145, 1); 
  --text-brand-blue-bolder: rgba(0, 100, 145, 1); 
  --text-white: rgba(255, 255, 255, 1); 
  ...
}

/* Tokens for dark mode - CSS variables */
@mixin modes--dark--css-vars {
  --text-primary: rgba(245, 245, 245, 1); 
  --text-secondary: rgba(245, 245, 245, 1); 
  --text-black: rgba(57, 51, 54, 1); 
  --text-brand-blue-default: rgba(0, 100, 145, 1); 
  --text-brand-blue-bold: rgba(24, 147, 204, 1); 
  --text-brand-blue-bolder: rgba(245, 245, 245, 1); 
  --text-white: rgba(255, 255, 255, 1); 
  ...
}

And add them to the :root {} like this:

@import "design-tokens/collection-modes--light--css-vars.scss";
@import "design-tokens/collection-modes--dark--css-vars.scss";

:root {
  @include modes--light--css-vars;

  @media (prefers-color-scheme: dark) {
    @include modes--dark--css-vars;
  }
}

This makes the CSS variables accessible across all pages of our application. They can be easily integrated into the front-end code, enabling smooth toggling between light and dark modes based on user preferences or system settings.

Challenges and Solutions

During the implementation process, we faced several challenges:

1. Figma Variables Errors: Initially, our Figma file wasn’t optimally structured for API consumption. Some Figma variables used in designs came from unpublished collections, which caused misunderstandings between the dev and designs teams. We had to work closely with our design team to debug this issue, ensuring that the variables used in designs came only from published collections and that our generated design tokens matched those used in designs.
2. API Rate Limits: We encountered Figma’s API rate limits when fetching data frequently. To address this, we implemented a caching system that stores the fetched data locally and only updates it when triggered by a command.

Case Study: Adding Light and Dark Themes To Our Button Component

To illustrate the impact of our new system, let’s look at how it improved our button component.

Before implementing design tokens, our UI library only supported light theme, and adding a dark one was going to be a time-consuming process.

For all the colour variables in our system, we used generic naming conventions which were not specific enough to allow for easy theme switching.

For example, $base-utility-primary was used in all the components that needed that shade of green colour, and changing this variable (like adding a dark theme) would have affected many elements in our UI library.

This was neither right nor wrong; it was just the way things were done when designs were initially created for our UI components library.

With Figma variables in place, UX designers are more specific when defining colour names. Here, you can see variables created specifically for the button component:

These are then automatically fetched and converted into CSS variables in our design tokens system:

And now, our button component uses these variables:

.button-primary {
  background-color: var(--button-surface-primary);

  &:hover {
    background-color: var(--button-surface-primary-hover);
  }

  &:active {
    background-color: var(--button-surface-primary-active);
  }
}

Which produces neatly looking buttons supporting both light and dark modes:

When the design team updates the button colours in Figma, the changes are automatically reflected in our UI library. And once design tokens have been added to the remaining projects, this process will significantly reduce development time and ensure consistency.

The Road Ahead for Design Tokens at Domino’s

While we’ve made significant progress in integrating Figma’s Variables API into our development workflow, the project is still ongoing. Our goal is to fully implement design tokens across all projects, ensuring a unified, scalable approach to UI development.

The benefits we’ve already seen include:

• Streamlined theme management
• Smoother collaboration between design and development teams
• Reduced time spent on manual updates

As we continue to refine our implementation, I am excited to see how this approach evolves and how it will shape the future of UI development at Domino’s.

Our next steps include:

1. Refining our automation process
2. Integrating tokens across more projects
3. Exploring how the design tokens can improve new projects we take on in the future

By staying focused on this ongoing work, I am confident our efforts will result in a more cohesive, efficient, and scalable design system for all of Domino’s digital experiences.

I encourage other teams facing similar challenges to explore Figma’s Variables API and the concept of design tokens. While the implementation process requires effort, the long-term benefits of consistency, efficiency, and scalability are well worth it.

Glossary of Terms

• Design Tokens: Centralised design values (like colours, fonts, sizes) that can be shared across projects.
• Figma: A collaborative interface design tool.
• Variables API: An API provided by Figma that allows access to design variables defined in Figma files.
• CSS Variables: Also known as CSS custom properties, these entities contain specific values to be reused throughout a document.
• SCSS: A preprocessor scripting language interpreted or compiled into Cascading Style Sheets (CSS).
• Node.js: An open-source, cross-platform JavaScript runtime environment.