Design Tokens in Code: Style Dictionary to Production

In modern organizations, products live on Web (React/Next.js), iOS (Swift/SwiftUI), and Android (Kotlin/Jetpack Compose).

Historically, when brand colors changed, designers notified web developers via Slack, iOS developers via Jira, and Android developers via email. Inevitably, hex values drifted, naming conventions diverged, and platforms fell out of sync.

Created by Amazon and maintained by the open-source community, Style Dictionary is a build system that ingests platform-neutral design token definitions (JSON/YAML) and transforms them into native delivery formats:

• Web: CSS Custom Properties, SCSS variables, JavaScript/TypeScript constants, Tailwind config.
• iOS: Swift structs, Objective-C constants, UIKit Color assets.
• Android: XML resources, Jetpack Compose theme objects.
• Flutter: Dart theme classes.

Instead of manual code translation, running style-dictionary build generates 100% accurate code for all targets in milliseconds.

To prevent vendor lock-in between Figma, Token Studio, and code compilers, the W3C DTCG established a standardized JSON format:

{
  "color": {
    "interactive": {
      "primary": {
        "$value": "#0066cc",
        "$type": "color",
        "$description": "Used for primary call-to-action buttons and focused inputs"
      }
    }
  },
  "space": {
    "md": {
      "$value": "16px",
      "$type": "dimension"
    }
  }
}

Using $value, $[type](/glossary/typography), and $description enables automated linters to validate that color values are valid hex/OKLCH and dimension tokens use valid spatial units.

How do tokens travel from a designer's brain to a developer's IDE without human copy-pasting?

1. Design Authoring: Designers update color or radius variables in Figma.
2. Export Trigger: A GitHub Action calls the Figma REST API (/v1/files/:file_key/variables/local) or uses a plugin like Token Studio.
3. Pull Request Generated: The script converts Figma variables into standard DTCG JSON and opens an automated PR in the design token repository.
4. Automated CI Build: GitHub Actions runs Style Dictionary, compiles Swift, Kotlin, and CSS, runs visual regression tests, and tags a new npm/Cocoapods package.

Different programming languages represent data differently. Style Dictionary uses Transforms to adapt values:

• Name Transforms: color-primary (kebab-case in CSS) $\rightarrow$ colorPrimary (camelCase in Swift/Kotlin) $\rightarrow$ COLOR_PRIMARY (constant in C++).
• Value Transforms: 16px in CSS $\rightarrow$ 16.dp in Android $\rightarrow$ CGFloat(16) in iOS SwiftUI.
• Color Transforms: #ffffff $\rightarrow$ Color(red: 1.0, green: 1.0, blue: 1.0) in Swift.

Transforms guarantee that engineers write idiomatic code on their respective platforms without arguing over naming conventions.

Modern frontend teams frequently pair design systems with Tailwind CSS. Instead of hardcoding arbitrary values (p-[13px]), the Tailwind theme configuration is derived directly from compiled design tokens:

// tailwind.config.js derived from design-tokens.json
module.exports = {
  theme: {
    colors: {
      primary: 'var(--color-interactive-primary)',
      surface: 'var(--color-surface-base)',
    },
    spacing: {
      sm: 'var(--space-sm)', // 8px
      md: 'var(--space-md)', // 16px
      lg: 'var(--space-lg)', // 24px
    },
  },
};

Developers write standard utility classes (bg-primary p-md), but Tailwind outputs CSS custom properties connected to the living design system.

Design token repositories must be versioned with strict Semantic Versioning (SemVer):

• PATCH (1.0.1): Tuning an existing color by a few percent for better contrast; zero API changes.
• MINOR (1.1.0): Introducing new tokens (e.g. adding color-accent-amber); backwards compatible.
• MAJOR (2.0.0): Renaming or deleting an existing token (e.g. deleting color-brand-legacy); breaking change that requires consumer migration.

Automated tools like Changesets prevent breaking changes from slipping into consumer apps unnoticed.

Creating design tokens does nothing if developers hardcode #3b82f6 or padding: 14px directly in CSS files.

Design system teams enforce ESLint and Stylelint rules:

• stylelint-declaration-strict-value: Blocks raw hex colors, pixel values, and font-families, requiring token variables.
• eslint-plugin-jsx-a11y: Enforces accessible names on icon buttons.

If a developer writes color: #ff0000;, CI fails immediately with: 'Error: Direct hex colors forbidden. Use var(--color-feedback-error) instead.'

Documentation should never be a manual static wiki. Using tools like Storybook, Docusaurus, or zeroheight, token spec pages are generated directly from the token JSON:

• Color swatches display computed HEX, RGB, OKLCH, and [WCAG contrast](/glossary/contrast-ratio) against white/black.
• Typography specimens display live rendered font scales with copyable CSS snippets.
• Spacing scales render interactive visual bounding boxes.

When tokens update in Git, documentation updates automatically on deploy.

The design token specification is expanding beyond simple scalar values (colors, numbers) into Composite Tokens:

• Typography Tokens: A composite object bundling font-family, weight, size, line-height, and letter-spacing.
• Shadow Tokens: Bundling X-offset, Y-offset, blur, spread, and color into a single cohesive elevation token.
• Motion Tokens: Bundling duration (250ms) and cubic-bezier easing curve (cubic-bezier(0.4, 0, 0.2, 1)).

Composite tokens allow complex sensory decisions to be authored once and shared across entire engineering organizations.