3.7 Existing Approaches and Pain Points

Studies show that when designers and developers do not work in sync, it can harm team productivity, clarity, and focus. Maudet et al. (2017) showed that designers often create multiple documents to explain different aspects of a design, yet developers still misinterpret them. This misalignment can lead to visual mismatches and missing information, especially when developers join the process late. Early developer involvement was shown to improve collaboration and reduce rework (Maudet et al., 2017).

In response to the designer and developer gaps, design systems have become a structured way to manage and align design decisions across teams. As Stepanova (2021) describes, they serve as communication artefacts that improve collaboration by making visual rules explicit. However, while design systems help reduce misunderstandings, they do not automatically ensure synchronization between design tools like Figma and frontend codebases.

To achieve this, design systems benefit from a clear Source of Truth (SoT). In this context, SOT refers to the authoritative location where all approved design tokens, components, and style definitions are maintained and updated (UXPin, n.d).

To address this, several solutions have been developed that aim to connect design and development. As part of our literature review, we identified the following key approaches in the industry:

1. Supernova The top contributor that tackles this challenge is Supernova. It is an integrated platform for managing design systems that allows teams to manage both design and engineering data centrally. It connects Figma files to the Supernova design system, allowing designers to import collections, variables, and modes directly via the Supernova Figma plugin. Any changes made in the Figma design file are automatically updated in Supernova, reducing the need for manual handoffs. Finally, design and code are connected by automating code delivery through code pipelines that depend on exporters to deliver design tokens to the respective codebases.

2. Token Studio for Figma Tokens Studio for Figma is a plugin that allows designers to define and manage design tokens directly within Figma. These tokens can be linked to Figma variables and styles, making it easier to maintain consistency and apply themes across a design. Tokens Studio supports advanced features like multi-theme management, dynamic token sets, version control, and JSON export for code integration via tools like Style Dictionary. It also integrates with external platforms, including Supernova, allowing token data to be part of a larger design system workflow.

3. Figma-to-Code Plugins Various marketplace plugins attempt to bridge design and code by exporting Figma designs to formats like HTML, CSS, React, and Flutter. While many offer quick results, the generated code typically lacks design system structure.

4. Figma Dev Mode Figma’s native Dev Mode allows developers to inspect design elements, view properties, track changes, and copy generated code snippets. With VS Code integration, designers and developers can explore design files directly within their editor. Dev Mode can reference design variables and tokens when they are present; otherwise, it displays the raw values in the format of the CSS custom property fallback syntax.

We found that Supernova and Tokens Studio currently offer the most comprehensive solutions in this field. As Piirainen (2023) demonstrates, using these tools makes it possible to transform Figma tokens into code through a combination of Tokens Studio for token creation and Supernova for design system management and code export. However, Piirainen also notes that this workflow has significant limitations: it relies heavily on external tools, requires manual setup, and introduces friction through configuration overhead. Additionally, both tools follow a design token–driven approach, which has inherent drawbacks. In our view, token management can be rigid and time-consuming, particularly for designers unfamiliar with structured naming conventions or cross-theme consistency. This rigidity may stifle creativity and create bottlenecks for teams without dedicated design-ops support.

Limitations

While existing approaches address some of the challenges in bridging design and development workflows, important limitations remain. Many solutions require full adoption of a comprehensive design system infrastructure, which can be impractical for teams without the resources to maintain it. They often introduce configuration overhead and depend on external tools, which slows down iteration. In addition, current solutions are primarily designed for design-first workflows and do not fully support scenarios where the source of truth originates in code. As a result, smaller teams, early-stage projects, and code-driven design systems remain underserved. These groups need a lightweight and direct way to synchronize Figma design tokens and CSS variables without the complexity of external pipelines.

Pain Points (PP)

Our analysis identified recurring pain points that disrupt the collaboration between design and development:

PP001 - One-way Synchronization

Design-to-code synchronization typically flows in one direction, with Figma as the source. Changes travel through tools like Tokens Studio and Supernova before reaching code. When the codebase evolves first, updates must be re-entered manually in Figma, which breaks alignment and increases drift.

Current state: manual import and structural limitations

• No direct import from code to Figma. Figma provides no built-in way to ingest CSS variables or color tokens from the codebase into variables or styles. This forces teams to rebuild definitions manually inside Figma.

• Error-prone workflows. Copy/paste and manual recreation frequently introduce mismatches between Figma artifacts and production CSS, especially across larger systems or when multiple contributors are involved.

• Dev Mode does not solve import. Even with Dev Mode, there is no mechanism to import CSS variables from code into Figma variables or styles.

Without a code-to-design import path, teams cannot maintain a truly bidirectional workflow that keeps design tokens synchronized. Bidirectional sync keeps code and Figma aligned, reduces drift and rework, shortens feedback loops, enables safe updates to design tokens, and sustains consistency across themes, components, and platforms as the system grows.

PP002 - Manual and Fragmented Variable Export

While third-party solutions such as Tokens Studio, Supernova, and Style Dictionary can automate the export of Figma variables into production-ready formats, they often require licensing costs. As a result, many teams still rely on Figma’s native capabilities, which lack a simple, built-in way to export variables at scale. Without adopting external tooling, the process remains manual and fragmented, slowing handoff and risking inconsistencies.

Current state: manual export workflows and tool limitations

• No native bulk export. Figma shows variable and style names and values in the UI but does not provide a native, production-ready CSS export. Developers must recreate variables one by one, copying names and values manually.

• Dev Mode is scoped, not systemic. Dev Mode exposes code snippets such as height: var(--Kolibri-Spacer-l, 24px); for selected elements, but it cannot export comprehensive token sets or generate a complete CSS variables file for all themes, modes, and states.

• Limited support for modern CSS patterns. Existing export paths rarely handle advanced, production patterns like color-mix(), light-dark(), or nested var() references. As a result, teams must retrofit modern CSS manually after export, duplicating effort and risking drift.

PP003 - Manual Variable & Style Management

Creating and updating color variables, styles, and palettes often requires repetitive manual work in both Figma and code. This increases the likelihood of human error and slows iteration speed.

PP004 - Inefficient Color Exploration in Native Figma

Finding the right colors for themes or palettes is often a slow, manual process. Designers must adjust individual swatches and test them in context, making theme creation time-consuming and error-prone. Once colors are finalized, each one still needs to be saved as a variable or style, which circles back to PP003. A typical workflow that demonstrates this pain point is:

Current User Flow of creating a color palette in Figma

1

Arrange Base Colors

As shown in Figure 35, designers begin by placing a set of rectangles or squares on the canvas to represent each color. These shapes act as swatches for building the palette. Colors are filled in using the color picker, which supports various input formats such as HEX, RGB, and HSL. If reference colors already exist, for example, from a mood board or an external palette generator, they can be sampled directly using the eyedropper tool. See the chapter Color Selection Process in UI to find out more on how designers choose their base colors.

Figure 35: Step 1 – Arranging base colors in Figma

2

Create Variables or Styles

Once a color is applied to a shape, a new variable or style must be created manually for that color. At the top of the color picker modal (see Figure 36), the user clicks the plus icon to initiate this process. This opens a second modal window (see Figure 37 and Figure 38).

Figure 36: Color Picker Modal

Figure 37: Style Modal

Figure 38: Variable Modal

3

Name and Organize

In the modal, users can choose between creating a color style or a variable. This follows the naming structure outlined in the theoretical background of Design Tokens in Figma. Ideally, all colors land in the same folder; in our example, we organise all colors in the folder/group purple.

4

Repeat the steps

This process must be repeated for every single color in the palette. As a result, we get the color styles purple 100-900 (see Figure 39).

Figure 39: Color palette saved as styles

or the variable collection with purple variables 100-900.

Figure 40: Color palette saved as variables

5

Apply color palette to designs

Once defined, these variables or styles are available for use in the library. Designers can access them through the design panel to ensure consistency across the UI.

PP005 – Lack of a clear Source of Truth

In many workflows, design tokens and style definitions are maintained in separate environments. Changes in one environment must be manually replicated in the other, which leads to drift and uncertainty about which version is authoritative. Without a shared, synchronized source of truth, both designers and developers risk working with outdated or inconsistent information.

These recurring pain points highlight the need for a more streamlined and flexible solution that supports bidirectional synchronization and maintains a single, reliable source of truth between design and code. Building on this analysis, the next chapter introduces our proposed solution.