The Figma-to-Code Workflow That Actually Works: Design Tokens for React Teams

Every design-engineering team has lived through the same painful loop. A designer builds a polished screen in Figma. A developer rebuilds it in React. Three weeks later the shipped product looks nothing like the design. Colors are slightly off. Spacing is inconsistent. Corners are rounded differently on every page. The designer opens a Jira ticket. The developer says "that's what the design shows." Both are right and both are frustrated.

The problem is not the people. The problem is the workflow. Most figma to code processes rely on visual eyeballing, screenshot comparisons, and manual translation—and that approach does not scale. This post covers a workflow that actually works: design tokens as the shared contract between Figma and your React codebase.

Why Most Figma-to-Code Workflows Fail

There are two root causes behind nearly every design-to-code breakdown.

Manual Translation

A designer sets a button background to #2563EB. A developer sees "blue" in the Figma inspect panel and types bg-blue-600 in Tailwind. Those values might match today—but they diverge the moment someone changes the brand color in Figma without updating the Tailwind config, or vice versa. Every hand-typed value is a point of potential drift.

Multiply this by every color, spacing value, font size, border radius, and shadow in your product, and you get a system where the design file and the codebase are two separate sources of truth that slowly diverge over time.

Style Drift Across Iterations

Products iterate. A designer updates spacing from 16px to 20px in one component but not others. A developer uses p-4 in one place and p-5 in another because both "looked right." Over six months, the product accumulates dozens of these micro-inconsistencies. No single one is catastrophic, but together they erode the visual quality and brand cohesion that makes a product feel polished.

This is the problem that design token systems solve—and figma to code workflows need to be built on top of them.

What Design Tokens Are and How They Bridge the Gap

Design tokens are named, platform-agnostic values that represent the fundamental building blocks of your UI: colors, spacing, typography, border radii, shadows, and more. Instead of hard-coding #2563EB in your Figma file and bg-blue-600 in your Tailwind config, you create a shared abstraction:

• Token name: color-primary-600
• Figma value: #2563EB (set as a Figma Variable)
• Code value: var(--color-primary-600) (a CSS custom property)
• Tailwind mapping: primary-600 (resolved via the Tailwind config)

The token is the contract. Figma and code both reference the same semantic name. When the value changes, it changes in one place and propagates everywhere.

This is not theoretical. It is the architecture behind every component in the thefrontkit SaaS Starter Kit and the Tailwind SaaS Template. Designers and developers work from the same token set, so there is no translation step and no drift.

Setting Up Figma Variables That Map to CSS Custom Properties

Figma's Variables feature (introduced in 2023 and expanded since) is the key to making this work on the design side. Here is how to structure your Figma variables so they map cleanly to CSS custom properties.

Step 1: Create a Token Collection in Figma

In your Figma file, create a Variable collection called Tokens. Inside it, create groups that mirror your CSS custom property namespace:

• color/primary/50 through color/primary/900
• color/secondary/100 through color/secondary/800
• color/neutral/50 through color/neutral/900
• color/success, color/warning, color/danger
• spacing/1 through spacing/16
• radius/sm, radius/md, radius/lg, radius/xl
• font-size/xs through font-size/4xl

Step 2: Use Modes for Light and Dark Themes

Figma Variables support modes. Create two modes—Light and Dark—within your color collection. The token names stay the same; only the values change per mode. This mirrors how CSS custom properties work with a [data-theme="dark"] selector:

:root {
  --color-primary-600: #2563EB;
  --color-neutral-50: #F9FAFB;
  --color-neutral-900: #111827;
}

[data-theme="dark"] {
  --color-primary-600: #60A5FA;
  --color-neutral-50: #1F2937;
  --color-neutral-900: #F9FAFB;
}

When a designer applies color/primary/600 to a Figma component and toggles to Dark mode, the variable resolves to the dark value automatically. The same thing happens in code when the data-theme attribute changes. No manual overrides needed.

Step 3: Apply Variables to Components, Not Raw Values

The discipline here is critical. Designers should never apply a raw hex value to a component. Every fill, stroke, spacing value, and radius should reference a variable. If a designer needs a color that does not exist in the token set, that is a signal to add a new token—not to hard-code a value.

Mapping Figma Tokens to Tailwind CSS Config

On the code side, your Tailwind config becomes the single place where tokens are defined and consumed. Here is a real-world example of how this mapping works.

Colors

// tailwind.config.ts
const config = {
  theme: {
    extend: {
      colors: {
        primary: {
          50: "var(--color-primary-50)",
          100: "var(--color-primary-100)",
          200: "var(--color-primary-200)",
          300: "var(--color-primary-300)",
          400: "var(--color-primary-400)",
          500: "var(--color-primary-500)",
          600: "var(--color-primary-600)",
          700: "var(--color-primary-700)",
          800: "var(--color-primary-800)",
          900: "var(--color-primary-900)",
        },
        secondary: {
          100: "var(--color-secondary-100)",
          200: "var(--color-secondary-200)",
          300: "var(--color-secondary-300)",
        },
      },
    },
  },
}

Every Tailwind utility class like bg-primary-600 or text-secondary-200 now resolves to a CSS custom property. Change the custom property value, and every component updates instantly—in both light and dark modes.

Spacing

spacing: {
  "token-1": "var(--spacing-1)",   // 4px
  "token-2": "var(--spacing-2)",   // 8px
  "token-3": "var(--spacing-3)",   // 12px
  "token-4": "var(--spacing-4)",   // 16px
  "token-6": "var(--spacing-6)",   // 24px
  "token-8": "var(--spacing-8)",   // 32px
}

Border Radius

borderRadius: {
  "token-sm": "var(--radius-sm)",   // 4px
  "token-md": "var(--radius-md)",   // 8px
  "token-lg": "var(--radius-lg)",   // 12px
  "token-xl": "var(--radius-xl)",   // 16px
}

Typography

fontSize: {
  "token-xs": "var(--font-size-xs)",     // 12px
  "token-sm": "var(--font-size-sm)",     // 14px
  "token-base": "var(--font-size-base)", // 16px
  "token-lg": "var(--font-size-lg)",     // 18px
  "token-xl": "var(--font-size-xl)",     // 20px
  "token-2xl": "var(--font-size-2xl)",   // 24px
}

The naming convention is intentional. Prefixing with token- makes it clear in your JSX that you are using a design token, not a default Tailwind value.

Keeping Design and Code in Sync Across Iterations

Having the mapping is step one. Keeping it in sync across sprints, rebrand cycles, and team changes is the harder problem. Here is a practical approach.

Single Source of Truth

Decide which side is authoritative. For most teams, the Figma file should be the source of truth for token values, and the code should be derived from it. This means when a designer changes color/primary/600 from #2563EB to #1D4ED8, the developer updates the corresponding CSS custom property. One direction, no ambiguity.

Automated Token Export

Tools like Tokens Studio (formerly Figma Tokens) or custom Figma plugins can export your variable collections as JSON. That JSON can be transformed into CSS custom properties, Tailwind config values, or any other format your build pipeline needs. The pipeline looks like this:

1. Designer updates a Figma Variable
2. Export script generates a tokens.json file
3. A build step transforms tokens.json into tokens.css (CSS custom properties)
4. Tailwind config references those custom properties
5. Components update automatically

Review Tokens in PRs

Treat token changes like API changes. When a PR modifies tokens.css or the Tailwind config's token mappings, flag it for design review. This prevents accidental drift and ensures the designer agrees with every token change that ships.

Real-World Examples from thefrontkit

The thefrontkit SaaS Starter Kit and Tailwind SaaS Template are built entirely on this token architecture. Here is how specific design decisions map from Figma to code.

Colors

Every component in the kit references semantic color tokens rather than raw values. A button's background is bg-primary-600, its hover state is bg-primary-700, and its disabled state is bg-primary-300. These all resolve to CSS custom properties, which means rebranding is a matter of updating the :root values—not touching component code.

The same token set drives light and dark themes. A card background might be bg-neutral-50 in light mode and bg-neutral-800 in dark mode, controlled entirely through the mode-based custom property override.

Spacing

Consistent spacing is one of the hardest things to maintain across a product. In the kit, every padding, margin, and gap value is pulled from the spacing token scale. A card uses p-token-4 (16px) internally. A section uses gap-token-6 (24px) between elements. These values are identical in the Figma file and the code because they reference the same token.

Typography

Font sizes, weights, and line heights are tokenized. Headings, body text, labels, and helper text all pull from the same type scale. When a designer adjusts the base font size in Figma, the corresponding CSS custom property updates, and every component using text-token-base reflects the change.

Border Radius

The kit uses a consistent radius scale: radius-sm for inputs, radius-md for cards, radius-lg for modals, radius-xl for larger containers. This eliminates the common problem where one developer rounds corners at 6px, another at 8px, and a third at 12px on the same type of element.

Benefits for Design-Engineering Teams

Adopting a token-based figma to code workflow changes team dynamics in several concrete ways.

Faster Handoffs

There is no "handoff" in the traditional sense. Designers and developers are working from the same token vocabulary. When a designer says "use primary-600 with spacing-4 and radius-md," the developer knows exactly which Tailwind classes to use. No ambiguity, no screenshots, no back-and-forth.

Fewer Visual Bugs

When every value in the codebase traces back to a named token, visual bugs become easier to find and fix. Instead of searching for every instance of #2563EB across your codebase, you update --color-primary-600 in one place. Instead of auditing padding values across fifty components, you check that they all use the correct spacing token.

Painless Rebranding

Products rebrand. If your values are hard-coded, a rebrand means touching hundreds of files. If your values are tokenized, a rebrand means updating a single CSS file. The Tailwind SaaS Template demonstrates this: swap the token values and the entire UI updates—every component, every page, light and dark modes included.

Better Cross-Functional Collaboration

Tokens give designers and developers a shared language. Design reviews become more productive because both sides are speaking in terms of primary-600 and spacing-4, not "that blue" and "about 16 pixels." This shared vocabulary reduces miscommunication and builds trust between disciplines.

Scalability

As your product grows—more pages, more features, more team members—a token-based system scales where manual translation does not. New developers can look at the token set and immediately understand the design system's constraints. New designers can use the Figma variables and know their choices will translate accurately to code.

Getting Started

If you want to see this workflow in practice rather than building it from scratch, the SaaS Starter Kit ships with a complete token system: Figma variables, CSS custom properties, Tailwind config mappings, and React components that consume them. Every component is accessible to WCAG AA standards, and light/dark themes are driven entirely by the token layer.

You can also start by exploring the Tailwind SaaS Template to see how token-driven theming works across a full set of SaaS UI patterns—auth flows, dashboards, settings pages, and more.

The goal is not a perfect process. The goal is eliminating the category of bugs that come from manual translation between design tools and code. Design tokens do that. A good figma to code workflow is just the discipline to use them consistently.