What Are Design Tokens? A Practical Guide for SaaS Teams
Design tokens turn scattered color codes and spacing values into a single source of truth. Here's what they are, how they work, and when they're worth the investment.
TL;DR
TL;DR
Every SaaS product hits a point where design consistency breaks down. Maybe your primary blue is slightly different across three screens. Maybe a rebrand means hunting through hundreds of files to update a single color. Design tokens solve this. They're the smallest building blocks of a design system, and they turn individual design decisions into reusable, platform-agnostic data. At Donux, we've built design systems with tokens for 80+ SaaS companies. This guide covers what tokens are, how they work in practice, and when they're worth your team's time.
Every SaaS product hits a point where design consistency breaks down. Maybe your primary blue is slightly different across three screens. Maybe a rebrand means hunting through hundreds of files to update a single color. Design tokens solve this. They're the smallest building blocks of a design system, and they turn individual design decisions into reusable, platform-agnostic data. At Donux, we've built design systems with tokens for 80+ SaaS companies. This guide covers what tokens are, how they work in practice, and when they're worth your team's time.
What are design tokens?
A design token is a design decision stored as data. Instead of hardcoding #3B82F6 into your CSS, you store that value once and reference it by name everywhere.
The term was coined by Jina Anne while working on Salesforce's Lightning Design System around 2014. The idea: separate what a design value means from where it's used.
Tokens typically represent:
Colors (brand, text, background, border)
Typography (font family, size, weight, line height)
Spacing (padding, margins, gaps)
Shadows (elevation levels)
Border radius (corner rounding)
Animation (duration, easing)
The key difference between tokens and regular variables? Tokens are platform-agnostic. They're stored as JSON (or YAML), then transformed into whatever format each platform needs: CSS custom properties, Swift constants, Android XML, Kotlin, SCSS variables.
The 3-tier token taxonomy
Most mature design systems organize tokens into three levels. This taxonomy is used by Salesforce, Google Material Design 3, and the W3C Design Tokens Community Group specification.
Primitive tokens (global)
Raw values with no contextual meaning.
These are your palette. They define what values exist, not where they're used.
Semantic tokens (alias)
Map primitive values to contextual purposes.
This is where tokens become powerful. When you rebrand, you change color-primary from {blue-500} to {green-600}, and every component using color-primary updates automatically.
Component tokens
Scope values to specific UI elements.
Component tokens give you fine-grained control without breaking the system. You can change every button's hover state in one place.
Real-world example: When Spotify rebranded in 2015, updating their signature green across all platforms took months of manual work. With semantic tokens, that same change would propagate in minutes. Spotify later invested heavily in semantic token layers specifically because they discovered primitive tokens alone weren't enough.
Design tokens vs. CSS variables
This is one of the most common points of confusion. They're related but different.
Design tokens | CSS custom properties | |
|---|---|---|
Format | Platform-agnostic (JSON/YAML) | CSS only |
Scope | All platforms (web, iOS, Android) | Web only |
Runtime | Static, transformed at build time | Dynamic, changeable at runtime |
Theming | Source of truth that feeds themes | Implementation layer for themes |
CSS custom properties are one output of design tokens. If your SaaS only ships on the web, CSS variables might be enough. But the moment you add a mobile app, an email template system, or a white-label option, you need the platform-agnostic layer that tokens provide.
How design tokens work in practice
Here's a simplified workflow:
Define tokens in a central JSON file (or in Figma using Tokens Studio or Figma Variables)
Transform tokens using a tool like Style Dictionary (Amazon's open-source transformer) into platform-specific formats
Distribute tokens to each platform's codebase via npm packages, Git syncing, or a token management platform
Reference tokens in components instead of hardcoded values
When a designer updates a token value in Figma, the change flows through to code via the transformation pipeline. One change, every platform updated.
Tooling ecosystem
The token tooling space has matured significantly:
Style Dictionary - Amazon's open-source transformation tool. The most widely used
Tokens Studio - Figma plugin that syncs tokens with Git repositories
Figma Variables - Native Figma feature (released 2023) for managing tokens inside design files
Supernova - Enterprise token management platform
Specify - Design data automation
The W3C Design Tokens specification
In October 2025, the W3C Design Tokens Community Group released the first stable version of the Design Tokens specification. This is a major milestone.
Before this spec, every tool defined tokens differently. Now there's a shared standard backed by contributors from Adobe, Google, Microsoft, Meta, Figma, Salesforce, and Shopify.
What the spec standardizes:
Token file format (JSON)
Token types (color, dimension, font family, etc.)
Aliasing and referencing
Group structure
If you're starting a token system from scratch in 2026, build on the DTCG spec. It reduces vendor lock-in and makes your tokens portable across tools.
When do you actually need design tokens?
Tokens aren't always worth the investment. Here's a practical decision framework:
You probably need tokens if:
Multiple designers work on the same product
Your product ships on more than one platform (web + mobile)
You're planning or have completed a design system
You anticipate rebranding or supporting multiple themes (dark mode, white-label)
Your design-to-development handoff is inconsistent
You probably don't need tokens if:
You're a solo designer on a single-platform MVP
Your product has fewer than 10 screens
You're pre-product-market fit and still iterating rapidly on fundamentals
For SaaS products in the scale-up phase, tokens almost always pay off. The upfront effort is small compared to the maintenance cost of inconsistent design across a growing product.
Common pitfalls (and how to avoid them)
Naming is the hardest part
Naming tokens is the #1 pain point teams report. Terms like "global," "semantic," "primitive," and "alias" overlap and confuse people.
Pick a naming convention early and document it. Nathan Curtis (EightShapes) has written extensively on token naming taxonomy. The key principles:
Names should describe purpose, not appearance (
color-errornotcolor-red)Be consistent with hierarchy (
{category}-{property}-{variant}-{state})Document your naming convention so new team members don't create duplicates
Skipping the semantic layer
Many teams jump straight from primitive tokens to component tokens. This works initially but breaks down during rebrands, theme changes, or when adding dark mode. Spotify learned this the hard way and had to retrofit a semantic layer across their entire system.
Over-engineering for small teams
If you're a 2-person team building an MVP, a full token pipeline with Style Dictionary, CI/CD integration, and automated distribution is overkill. Start with Figma Variables and CSS custom properties. Add the infrastructure when your team or product complexity demands it.
Design tokens at Donux: what we've learned
We've implemented token systems across dozens of SaaS products. A few examples:
Up2You: We built a multi-brand design system with semantic tokens and 60+ components. The token architecture lets them maintain separate brand identities across products from a single system.
Ekore: Full platform redesign including a design system with tokens. The token layer powers their dark mode and Smart Monitoring module.
Fluida: Mobile-first design system ("Wave") with 40+ components across 4 products. Tokens keep the design language consistent across their entire HR tech suite. Fluida was acquired 15 months after the design system launched.
The pattern we see: teams that invest in tokens early spend less time fixing inconsistencies later. The ROI scales with product complexity.
Getting started
If you're ready to implement design tokens, start here:
Audit your current design decisions. List every color, spacing value, font size, and shadow in your product. You'll likely find duplicates and inconsistencies.
Define your primitive tokens. Establish the raw palette of values your product uses.
Add the semantic layer. Map primitives to purposes (primary, secondary, error, success, background, surface).
Pick your tooling. For most teams: Figma Variables + Style Dictionary is a solid starting stack.
Document your naming convention. Write it down before you have 200 tokens and 5 different naming patterns.
If your product already has a design system, tokens are the natural next step. If you're building a design system from scratch, tokens should be your foundation.
Need help setting up design tokens or a full design system for your SaaS product? Book a discovery call - we've done this 80+ times and would be happy to help.
Related reading
Design System: A Guide to Streamlined, Scalable Design - the companion guide to design tokens, covering the full design system picture
Design to Code with Framer: A Practical Handoff Guide - how tokens fit into the design-to-development handoff
What Is Product Design? How to Create User-Centric Products - the broader product design context for design decisions
UX Audit: Process, Checklist & Services for B2B SaaS - how a UX audit can reveal token inconsistencies in your product
What are design tokens?
A design token is a design decision stored as data. Instead of hardcoding #3B82F6 into your CSS, you store that value once and reference it by name everywhere.
The term was coined by Jina Anne while working on Salesforce's Lightning Design System around 2014. The idea: separate what a design value means from where it's used.
Tokens typically represent:
Colors (brand, text, background, border)
Typography (font family, size, weight, line height)
Spacing (padding, margins, gaps)
Shadows (elevation levels)
Border radius (corner rounding)
Animation (duration, easing)
The key difference between tokens and regular variables? Tokens are platform-agnostic. They're stored as JSON (or YAML), then transformed into whatever format each platform needs: CSS custom properties, Swift constants, Android XML, Kotlin, SCSS variables.
The 3-tier token taxonomy
Most mature design systems organize tokens into three levels. This taxonomy is used by Salesforce, Google Material Design 3, and the W3C Design Tokens Community Group specification.
Primitive tokens (global)
Raw values with no contextual meaning.
These are your palette. They define what values exist, not where they're used.
Semantic tokens (alias)
Map primitive values to contextual purposes.
This is where tokens become powerful. When you rebrand, you change color-primary from {blue-500} to {green-600}, and every component using color-primary updates automatically.
Component tokens
Scope values to specific UI elements.
Component tokens give you fine-grained control without breaking the system. You can change every button's hover state in one place.
Real-world example: When Spotify rebranded in 2015, updating their signature green across all platforms took months of manual work. With semantic tokens, that same change would propagate in minutes. Spotify later invested heavily in semantic token layers specifically because they discovered primitive tokens alone weren't enough.
Design tokens vs. CSS variables
This is one of the most common points of confusion. They're related but different.
Design tokens | CSS custom properties | |
|---|---|---|
Format | Platform-agnostic (JSON/YAML) | CSS only |
Scope | All platforms (web, iOS, Android) | Web only |
Runtime | Static, transformed at build time | Dynamic, changeable at runtime |
Theming | Source of truth that feeds themes | Implementation layer for themes |
CSS custom properties are one output of design tokens. If your SaaS only ships on the web, CSS variables might be enough. But the moment you add a mobile app, an email template system, or a white-label option, you need the platform-agnostic layer that tokens provide.
How design tokens work in practice
Here's a simplified workflow:
Define tokens in a central JSON file (or in Figma using Tokens Studio or Figma Variables)
Transform tokens using a tool like Style Dictionary (Amazon's open-source transformer) into platform-specific formats
Distribute tokens to each platform's codebase via npm packages, Git syncing, or a token management platform
Reference tokens in components instead of hardcoded values
When a designer updates a token value in Figma, the change flows through to code via the transformation pipeline. One change, every platform updated.
Tooling ecosystem
The token tooling space has matured significantly:
Style Dictionary - Amazon's open-source transformation tool. The most widely used
Tokens Studio - Figma plugin that syncs tokens with Git repositories
Figma Variables - Native Figma feature (released 2023) for managing tokens inside design files
Supernova - Enterprise token management platform
Specify - Design data automation
The W3C Design Tokens specification
In October 2025, the W3C Design Tokens Community Group released the first stable version of the Design Tokens specification. This is a major milestone.
Before this spec, every tool defined tokens differently. Now there's a shared standard backed by contributors from Adobe, Google, Microsoft, Meta, Figma, Salesforce, and Shopify.
What the spec standardizes:
Token file format (JSON)
Token types (color, dimension, font family, etc.)
Aliasing and referencing
Group structure
If you're starting a token system from scratch in 2026, build on the DTCG spec. It reduces vendor lock-in and makes your tokens portable across tools.
When do you actually need design tokens?
Tokens aren't always worth the investment. Here's a practical decision framework:
You probably need tokens if:
Multiple designers work on the same product
Your product ships on more than one platform (web + mobile)
You're planning or have completed a design system
You anticipate rebranding or supporting multiple themes (dark mode, white-label)
Your design-to-development handoff is inconsistent
You probably don't need tokens if:
You're a solo designer on a single-platform MVP
Your product has fewer than 10 screens
You're pre-product-market fit and still iterating rapidly on fundamentals
For SaaS products in the scale-up phase, tokens almost always pay off. The upfront effort is small compared to the maintenance cost of inconsistent design across a growing product.
Common pitfalls (and how to avoid them)
Naming is the hardest part
Naming tokens is the #1 pain point teams report. Terms like "global," "semantic," "primitive," and "alias" overlap and confuse people.
Pick a naming convention early and document it. Nathan Curtis (EightShapes) has written extensively on token naming taxonomy. The key principles:
Names should describe purpose, not appearance (
color-errornotcolor-red)Be consistent with hierarchy (
{category}-{property}-{variant}-{state})Document your naming convention so new team members don't create duplicates
Skipping the semantic layer
Many teams jump straight from primitive tokens to component tokens. This works initially but breaks down during rebrands, theme changes, or when adding dark mode. Spotify learned this the hard way and had to retrofit a semantic layer across their entire system.
Over-engineering for small teams
If you're a 2-person team building an MVP, a full token pipeline with Style Dictionary, CI/CD integration, and automated distribution is overkill. Start with Figma Variables and CSS custom properties. Add the infrastructure when your team or product complexity demands it.
Design tokens at Donux: what we've learned
We've implemented token systems across dozens of SaaS products. A few examples:
Up2You: We built a multi-brand design system with semantic tokens and 60+ components. The token architecture lets them maintain separate brand identities across products from a single system.
Ekore: Full platform redesign including a design system with tokens. The token layer powers their dark mode and Smart Monitoring module.
Fluida: Mobile-first design system ("Wave") with 40+ components across 4 products. Tokens keep the design language consistent across their entire HR tech suite. Fluida was acquired 15 months after the design system launched.
The pattern we see: teams that invest in tokens early spend less time fixing inconsistencies later. The ROI scales with product complexity.
Getting started
If you're ready to implement design tokens, start here:
Audit your current design decisions. List every color, spacing value, font size, and shadow in your product. You'll likely find duplicates and inconsistencies.
Define your primitive tokens. Establish the raw palette of values your product uses.
Add the semantic layer. Map primitives to purposes (primary, secondary, error, success, background, surface).
Pick your tooling. For most teams: Figma Variables + Style Dictionary is a solid starting stack.
Document your naming convention. Write it down before you have 200 tokens and 5 different naming patterns.
If your product already has a design system, tokens are the natural next step. If you're building a design system from scratch, tokens should be your foundation.
Need help setting up design tokens or a full design system for your SaaS product? Book a discovery call - we've done this 80+ times and would be happy to help.
Related reading
Design System: A Guide to Streamlined, Scalable Design - the companion guide to design tokens, covering the full design system picture
Design to Code with Framer: A Practical Handoff Guide - how tokens fit into the design-to-development handoff
What Is Product Design? How to Create User-Centric Products - the broader product design context for design decisions
UX Audit: Process, Checklist & Services for B2B SaaS - how a UX audit can reveal token inconsistencies in your product
What are design tokens?
A design token is a design decision stored as data. Instead of hardcoding #3B82F6 into your CSS, you store that value once and reference it by name everywhere.
The term was coined by Jina Anne while working on Salesforce's Lightning Design System around 2014. The idea: separate what a design value means from where it's used.
Tokens typically represent:
Colors (brand, text, background, border)
Typography (font family, size, weight, line height)
Spacing (padding, margins, gaps)
Shadows (elevation levels)
Border radius (corner rounding)
Animation (duration, easing)
The key difference between tokens and regular variables? Tokens are platform-agnostic. They're stored as JSON (or YAML), then transformed into whatever format each platform needs: CSS custom properties, Swift constants, Android XML, Kotlin, SCSS variables.
The 3-tier token taxonomy
Most mature design systems organize tokens into three levels. This taxonomy is used by Salesforce, Google Material Design 3, and the W3C Design Tokens Community Group specification.
Primitive tokens (global)
Raw values with no contextual meaning.
These are your palette. They define what values exist, not where they're used.
Semantic tokens (alias)
Map primitive values to contextual purposes.
This is where tokens become powerful. When you rebrand, you change color-primary from {blue-500} to {green-600}, and every component using color-primary updates automatically.
Component tokens
Scope values to specific UI elements.
Component tokens give you fine-grained control without breaking the system. You can change every button's hover state in one place.
Real-world example: When Spotify rebranded in 2015, updating their signature green across all platforms took months of manual work. With semantic tokens, that same change would propagate in minutes. Spotify later invested heavily in semantic token layers specifically because they discovered primitive tokens alone weren't enough.
Design tokens vs. CSS variables
This is one of the most common points of confusion. They're related but different.
Design tokens | CSS custom properties | |
|---|---|---|
Format | Platform-agnostic (JSON/YAML) | CSS only |
Scope | All platforms (web, iOS, Android) | Web only |
Runtime | Static, transformed at build time | Dynamic, changeable at runtime |
Theming | Source of truth that feeds themes | Implementation layer for themes |
CSS custom properties are one output of design tokens. If your SaaS only ships on the web, CSS variables might be enough. But the moment you add a mobile app, an email template system, or a white-label option, you need the platform-agnostic layer that tokens provide.
How design tokens work in practice
Here's a simplified workflow:
Define tokens in a central JSON file (or in Figma using Tokens Studio or Figma Variables)
Transform tokens using a tool like Style Dictionary (Amazon's open-source transformer) into platform-specific formats
Distribute tokens to each platform's codebase via npm packages, Git syncing, or a token management platform
Reference tokens in components instead of hardcoded values
When a designer updates a token value in Figma, the change flows through to code via the transformation pipeline. One change, every platform updated.
Tooling ecosystem
The token tooling space has matured significantly:
Style Dictionary - Amazon's open-source transformation tool. The most widely used
Tokens Studio - Figma plugin that syncs tokens with Git repositories
Figma Variables - Native Figma feature (released 2023) for managing tokens inside design files
Supernova - Enterprise token management platform
Specify - Design data automation
The W3C Design Tokens specification
In October 2025, the W3C Design Tokens Community Group released the first stable version of the Design Tokens specification. This is a major milestone.
Before this spec, every tool defined tokens differently. Now there's a shared standard backed by contributors from Adobe, Google, Microsoft, Meta, Figma, Salesforce, and Shopify.
What the spec standardizes:
Token file format (JSON)
Token types (color, dimension, font family, etc.)
Aliasing and referencing
Group structure
If you're starting a token system from scratch in 2026, build on the DTCG spec. It reduces vendor lock-in and makes your tokens portable across tools.
When do you actually need design tokens?
Tokens aren't always worth the investment. Here's a practical decision framework:
You probably need tokens if:
Multiple designers work on the same product
Your product ships on more than one platform (web + mobile)
You're planning or have completed a design system
You anticipate rebranding or supporting multiple themes (dark mode, white-label)
Your design-to-development handoff is inconsistent
You probably don't need tokens if:
You're a solo designer on a single-platform MVP
Your product has fewer than 10 screens
You're pre-product-market fit and still iterating rapidly on fundamentals
For SaaS products in the scale-up phase, tokens almost always pay off. The upfront effort is small compared to the maintenance cost of inconsistent design across a growing product.
Common pitfalls (and how to avoid them)
Naming is the hardest part
Naming tokens is the #1 pain point teams report. Terms like "global," "semantic," "primitive," and "alias" overlap and confuse people.
Pick a naming convention early and document it. Nathan Curtis (EightShapes) has written extensively on token naming taxonomy. The key principles:
Names should describe purpose, not appearance (
color-errornotcolor-red)Be consistent with hierarchy (
{category}-{property}-{variant}-{state})Document your naming convention so new team members don't create duplicates
Skipping the semantic layer
Many teams jump straight from primitive tokens to component tokens. This works initially but breaks down during rebrands, theme changes, or when adding dark mode. Spotify learned this the hard way and had to retrofit a semantic layer across their entire system.
Over-engineering for small teams
If you're a 2-person team building an MVP, a full token pipeline with Style Dictionary, CI/CD integration, and automated distribution is overkill. Start with Figma Variables and CSS custom properties. Add the infrastructure when your team or product complexity demands it.
Design tokens at Donux: what we've learned
We've implemented token systems across dozens of SaaS products. A few examples:
Up2You: We built a multi-brand design system with semantic tokens and 60+ components. The token architecture lets them maintain separate brand identities across products from a single system.
Ekore: Full platform redesign including a design system with tokens. The token layer powers their dark mode and Smart Monitoring module.
Fluida: Mobile-first design system ("Wave") with 40+ components across 4 products. Tokens keep the design language consistent across their entire HR tech suite. Fluida was acquired 15 months after the design system launched.
The pattern we see: teams that invest in tokens early spend less time fixing inconsistencies later. The ROI scales with product complexity.
Getting started
If you're ready to implement design tokens, start here:
Audit your current design decisions. List every color, spacing value, font size, and shadow in your product. You'll likely find duplicates and inconsistencies.
Define your primitive tokens. Establish the raw palette of values your product uses.
Add the semantic layer. Map primitives to purposes (primary, secondary, error, success, background, surface).
Pick your tooling. For most teams: Figma Variables + Style Dictionary is a solid starting stack.
Document your naming convention. Write it down before you have 200 tokens and 5 different naming patterns.
If your product already has a design system, tokens are the natural next step. If you're building a design system from scratch, tokens should be your foundation.
Need help setting up design tokens or a full design system for your SaaS product? Book a discovery call - we've done this 80+ times and would be happy to help.
Related reading
Design System: A Guide to Streamlined, Scalable Design - the companion guide to design tokens, covering the full design system picture
Design to Code with Framer: A Practical Handoff Guide - how tokens fit into the design-to-development handoff
What Is Product Design? How to Create User-Centric Products - the broader product design context for design decisions
UX Audit: Process, Checklist & Services for B2B SaaS - how a UX audit can reveal token inconsistencies in your product
What are design tokens?
A design token is a design decision stored as data. Instead of hardcoding #3B82F6 into your CSS, you store that value once and reference it by name everywhere.
The term was coined by Jina Anne while working on Salesforce's Lightning Design System around 2014. The idea: separate what a design value means from where it's used.
Tokens typically represent:
Colors (brand, text, background, border)
Typography (font family, size, weight, line height)
Spacing (padding, margins, gaps)
Shadows (elevation levels)
Border radius (corner rounding)
Animation (duration, easing)
The key difference between tokens and regular variables? Tokens are platform-agnostic. They're stored as JSON (or YAML), then transformed into whatever format each platform needs: CSS custom properties, Swift constants, Android XML, Kotlin, SCSS variables.
The 3-tier token taxonomy
Most mature design systems organize tokens into three levels. This taxonomy is used by Salesforce, Google Material Design 3, and the W3C Design Tokens Community Group specification.
Primitive tokens (global)
Raw values with no contextual meaning.
These are your palette. They define what values exist, not where they're used.
Semantic tokens (alias)
Map primitive values to contextual purposes.
This is where tokens become powerful. When you rebrand, you change color-primary from {blue-500} to {green-600}, and every component using color-primary updates automatically.
Component tokens
Scope values to specific UI elements.
Component tokens give you fine-grained control without breaking the system. You can change every button's hover state in one place.
Real-world example: When Spotify rebranded in 2015, updating their signature green across all platforms took months of manual work. With semantic tokens, that same change would propagate in minutes. Spotify later invested heavily in semantic token layers specifically because they discovered primitive tokens alone weren't enough.
Design tokens vs. CSS variables
This is one of the most common points of confusion. They're related but different.
Design tokens | CSS custom properties | |
|---|---|---|
Format | Platform-agnostic (JSON/YAML) | CSS only |
Scope | All platforms (web, iOS, Android) | Web only |
Runtime | Static, transformed at build time | Dynamic, changeable at runtime |
Theming | Source of truth that feeds themes | Implementation layer for themes |
CSS custom properties are one output of design tokens. If your SaaS only ships on the web, CSS variables might be enough. But the moment you add a mobile app, an email template system, or a white-label option, you need the platform-agnostic layer that tokens provide.
How design tokens work in practice
Here's a simplified workflow:
Define tokens in a central JSON file (or in Figma using Tokens Studio or Figma Variables)
Transform tokens using a tool like Style Dictionary (Amazon's open-source transformer) into platform-specific formats
Distribute tokens to each platform's codebase via npm packages, Git syncing, or a token management platform
Reference tokens in components instead of hardcoded values
When a designer updates a token value in Figma, the change flows through to code via the transformation pipeline. One change, every platform updated.
Tooling ecosystem
The token tooling space has matured significantly:
Style Dictionary - Amazon's open-source transformation tool. The most widely used
Tokens Studio - Figma plugin that syncs tokens with Git repositories
Figma Variables - Native Figma feature (released 2023) for managing tokens inside design files
Supernova - Enterprise token management platform
Specify - Design data automation
The W3C Design Tokens specification
In October 2025, the W3C Design Tokens Community Group released the first stable version of the Design Tokens specification. This is a major milestone.
Before this spec, every tool defined tokens differently. Now there's a shared standard backed by contributors from Adobe, Google, Microsoft, Meta, Figma, Salesforce, and Shopify.
What the spec standardizes:
Token file format (JSON)
Token types (color, dimension, font family, etc.)
Aliasing and referencing
Group structure
If you're starting a token system from scratch in 2026, build on the DTCG spec. It reduces vendor lock-in and makes your tokens portable across tools.
When do you actually need design tokens?
Tokens aren't always worth the investment. Here's a practical decision framework:
You probably need tokens if:
Multiple designers work on the same product
Your product ships on more than one platform (web + mobile)
You're planning or have completed a design system
You anticipate rebranding or supporting multiple themes (dark mode, white-label)
Your design-to-development handoff is inconsistent
You probably don't need tokens if:
You're a solo designer on a single-platform MVP
Your product has fewer than 10 screens
You're pre-product-market fit and still iterating rapidly on fundamentals
For SaaS products in the scale-up phase, tokens almost always pay off. The upfront effort is small compared to the maintenance cost of inconsistent design across a growing product.
Common pitfalls (and how to avoid them)
Naming is the hardest part
Naming tokens is the #1 pain point teams report. Terms like "global," "semantic," "primitive," and "alias" overlap and confuse people.
Pick a naming convention early and document it. Nathan Curtis (EightShapes) has written extensively on token naming taxonomy. The key principles:
Names should describe purpose, not appearance (
color-errornotcolor-red)Be consistent with hierarchy (
{category}-{property}-{variant}-{state})Document your naming convention so new team members don't create duplicates
Skipping the semantic layer
Many teams jump straight from primitive tokens to component tokens. This works initially but breaks down during rebrands, theme changes, or when adding dark mode. Spotify learned this the hard way and had to retrofit a semantic layer across their entire system.
Over-engineering for small teams
If you're a 2-person team building an MVP, a full token pipeline with Style Dictionary, CI/CD integration, and automated distribution is overkill. Start with Figma Variables and CSS custom properties. Add the infrastructure when your team or product complexity demands it.
Design tokens at Donux: what we've learned
We've implemented token systems across dozens of SaaS products. A few examples:
Up2You: We built a multi-brand design system with semantic tokens and 60+ components. The token architecture lets them maintain separate brand identities across products from a single system.
Ekore: Full platform redesign including a design system with tokens. The token layer powers their dark mode and Smart Monitoring module.
Fluida: Mobile-first design system ("Wave") with 40+ components across 4 products. Tokens keep the design language consistent across their entire HR tech suite. Fluida was acquired 15 months after the design system launched.
The pattern we see: teams that invest in tokens early spend less time fixing inconsistencies later. The ROI scales with product complexity.
Getting started
If you're ready to implement design tokens, start here:
Audit your current design decisions. List every color, spacing value, font size, and shadow in your product. You'll likely find duplicates and inconsistencies.
Define your primitive tokens. Establish the raw palette of values your product uses.
Add the semantic layer. Map primitives to purposes (primary, secondary, error, success, background, surface).
Pick your tooling. For most teams: Figma Variables + Style Dictionary is a solid starting stack.
Document your naming convention. Write it down before you have 200 tokens and 5 different naming patterns.
If your product already has a design system, tokens are the natural next step. If you're building a design system from scratch, tokens should be your foundation.
Need help setting up design tokens or a full design system for your SaaS product? Book a discovery call - we've done this 80+ times and would be happy to help.
Related reading
Design System: A Guide to Streamlined, Scalable Design - the companion guide to design tokens, covering the full design system picture
Design to Code with Framer: A Practical Handoff Guide - how tokens fit into the design-to-development handoff
What Is Product Design? How to Create User-Centric Products - the broader product design context for design decisions
UX Audit: Process, Checklist & Services for B2B SaaS - how a UX audit can reveal token inconsistencies in your product
Title
Got questions?
Do I need a full design system before implementing design tokens?
No. Tokens can be the starting point of a design system. Start with tokens for your core values (colors, typography, spacing), then build components on top of them. Many teams find that defining tokens naturally leads into building a component library.
Do I need a full design system before implementing design tokens?
No. Tokens can be the starting point of a design system. Start with tokens for your core values (colors, typography, spacing), then build components on top of them. Many teams find that defining tokens naturally leads into building a component library.
Do I need a full design system before implementing design tokens?
No. Tokens can be the starting point of a design system. Start with tokens for your core values (colors, typography, spacing), then build components on top of them. Many teams find that defining tokens naturally leads into building a component library.
How long does it take to set up design tokens?
For a typical SaaS product, defining and implementing a basic token system takes 1-2 weeks. The semantic layer and tooling pipeline might add another week. The investment pays back quickly through faster development and fewer design inconsistencies.
How long does it take to set up design tokens?
For a typical SaaS product, defining and implementing a basic token system takes 1-2 weeks. The semantic layer and tooling pipeline might add another week. The investment pays back quickly through faster development and fewer design inconsistencies.
How long does it take to set up design tokens?
For a typical SaaS product, defining and implementing a basic token system takes 1-2 weeks. The semantic layer and tooling pipeline might add another week. The investment pays back quickly through faster development and fewer design inconsistencies.
Can I use design tokens with Figma?
Yes. Figma Variables (released 2023) provide native token support. For more advanced workflows, Tokens Studio is a popular plugin that syncs Figma tokens with Git repositories. Both approaches work well, and the choice depends on your team's technical comfort level.
Can I use design tokens with Figma?
Yes. Figma Variables (released 2023) provide native token support. For more advanced workflows, Tokens Studio is a popular plugin that syncs Figma tokens with Git repositories. Both approaches work well, and the choice depends on your team's technical comfort level.
Can I use design tokens with Figma?
Yes. Figma Variables (released 2023) provide native token support. For more advanced workflows, Tokens Studio is a popular plugin that syncs Figma tokens with Git repositories. Both approaches work well, and the choice depends on your team's technical comfort level.
What happens to design tokens during a rebrand?
This is where tokens shine. With a semantic token layer, a rebrand means updating your primitive values (the raw colors, fonts) and possibly adjusting some semantic mappings. Every component referencing those tokens updates automatically. What used to take weeks of find-and-replace becomes a controlled, predictable process.
What happens to design tokens during a rebrand?
This is where tokens shine. With a semantic token layer, a rebrand means updating your primitive values (the raw colors, fonts) and possibly adjusting some semantic mappings. Every component referencing those tokens updates automatically. What used to take weeks of find-and-replace becomes a controlled, predictable process.
What happens to design tokens during a rebrand?
This is where tokens shine. With a semantic token layer, a rebrand means updating your primitive values (the raw colors, fonts) and possibly adjusting some semantic mappings. Every component referencing those tokens updates automatically. What used to take weeks of find-and-replace becomes a controlled, predictable process.
Are design tokens only for large teams?
Not necessarily. Even a 2-3 person team benefits from tokens if they're building a product that will scale. The key question is whether you expect your product's UI to grow in complexity. If yes, tokens prevent the design debt that accumulates when values are hardcoded across dozens of components.
Are design tokens only for large teams?
Not necessarily. Even a 2-3 person team benefits from tokens if they're building a product that will scale. The key question is whether you expect your product's UI to grow in complexity. If yes, tokens prevent the design debt that accumulates when values are hardcoded across dozens of components.
Are design tokens only for large teams?
Not necessarily. Even a 2-3 person team benefits from tokens if they're building a product that will scale. The key question is whether you expect your product's UI to grow in complexity. If yes, tokens prevent the design debt that accumulates when values are hardcoded across dozens of components.
What's the difference between Figma styles and design tokens?
Figma styles are Figma-specific. Design tokens are platform-agnostic data that can be transformed into Figma styles, CSS variables, Swift constants, and more. If you only design in Figma and only ship on the web, styles might be enough. But tokens give you a single source of truth that works across your entire stack.
What's the difference between Figma styles and design tokens?
Figma styles are Figma-specific. Design tokens are platform-agnostic data that can be transformed into Figma styles, CSS variables, Swift constants, and more. If you only design in Figma and only ship on the web, styles might be enough. But tokens give you a single source of truth that works across your entire stack.
What's the difference between Figma styles and design tokens?
Figma styles are Figma-specific. Design tokens are platform-agnostic data that can be transformed into Figma styles, CSS variables, Swift constants, and more. If you only design in Figma and only ship on the web, styles might be enough. But tokens give you a single source of truth that works across your entire stack.
