Sixty percent of design systems fail. That statistic from industry surveys gets cited constantly, and the usual follow-up advice is to hire a dedicated design system team, invest in complex tooling, and spend six months building before shipping anything useful.
That advice is why most fail. They collapse under their own ambition before delivering value to a single product team.
The W3C Design Tokens specification reached v1.0 in October 2025 — backed by Adobe, Amazon, Google, Meta, Microsoft, Salesforce, and Figma. Figma's Variables system has matured significantly with extended types, more modes per collection, and native import/export capabilities. Together, they make it possible to build a functional, maintainable design system using only native Figma features — no third-party plugins required for the initial build, no enterprise budget, no dedicated team.
Muzli Blog published a solid design system guide in February 2026, and the Design Systems Collective has a comprehensive playbook. But both lean heavily on philosophy and theory. This guide is the step-by-step build — tokens first, components second, dark mode automatic — that you can complete in a weekend and ship on Monday.
What you are building — and what you are deliberately not building
Building: A token-based foundation (colors, spacing, typography, radii) with five core components (Button, Input, Card, Badge, Dialog) that use Figma Variables for theming and mode switching. This covers 80% of what a product team needs day-to-day.
Not building: A 200-component library with documentation site, contribution guidelines, and cross-platform support. That is a year-long project. This is a weekend-to-week project that ships immediately useful results. The remaining components get added incrementally as real needs arise — not speculatively.
Why this order matters: Most design system guides start with components. Start with tokens instead. Components without tokens means every color, spacing value, and radius is hardcoded. Changing your primary blue later requires manually updating 47 components. With tokens, you change one variable and every component updates automatically.
Step 1 — define your color token architecture
Open a new Figma file. Create a Variable collection called "Colors" with two modes: Light and Dark.
Primitive color tokens (the raw values)
These are your absolute color values. They do not change between modes. They answer the question: "What colors exist in our palette?"
Create Variables:
blue/50throughblue/950(your full primary shade scale)gray/50throughgray/950(your neutral scale)green/500,green/600(success)amber/500,amber/600(warning)red/500,red/600(error)
You never apply primitives directly to design elements. They are ingredients, not recipes.
Semantic color tokens (what the colors mean)
These reference your primitives and change between Light and Dark modes. They answer: "How should colors be used?"
| Semantic Token | Light Value | Dark Value |
|---|---|---|
| color/bg/primary | gray/50 | gray/900 |
| color/bg/surface | white | gray/800 |
| color/bg/surface-raised | white | gray/700 |
| color/text/primary | gray/900 | gray/50 |
| color/text/secondary | gray/600 | gray/400 |
| color/text/disabled | gray/400 | gray/600 |
| color/brand/primary | blue/600 | blue/400 |
| color/brand/primary-hover | blue/700 | blue/300 |
| color/border/default | gray/200 | gray/700 |
| color/border/strong | gray/300 | gray/600 |
| color/status/success | green/600 | green/400 |
| color/status/warning | amber/600 | amber/400 |
| color/status/error | red/600 | red/400 |
This two-tier architecture — primitives holding raw values, semantics holding meaning — is the foundation. When you decide later that your primary blue should shift warmer, you change one primitive. Every semantic reference updates. Every component using those semantics updates. One change, full propagation.
<!-- IMAGE: Screenshot of Figma Variables panel showing the two-tier token architecture — primitives collection and semantics collection with Light/Dark modes visible. Alt text: "Figma Variables panel showing primitive and semantic color token architecture with Light and Dark modes." Host on mantlr.com/blog/images/ -->
Step 2 — spacing, sizing, and radius tokens
Create a second Variable collection called "Spacing" using number type.
Spacing scale:
space/1: 4pxspace/2: 8pxspace/3: 12pxspace/4: 16pxspace/5: 20pxspace/6: 24pxspace/8: 32pxspace/10: 40pxspace/12: 48pxspace/16: 64px
Apply these tokens to every Auto Layout padding and gap value in your components. Never type a raw pixel number for spacing. Always reference a token. This single discipline prevents the gradual drift that kills design systems — where one designer uses 14px padding and another uses 16px, and six months later your product has 23 different spacing values.
Border radius tokens:
radius/sm: 4pxradius/md: 8pxradius/lg: 12pxradius/xl: 16pxradius/full: 9999px
Step 3 — typography as styles
Figma Variables do not yet support typography as a variable type — this is a known limitation. Use Figma Text Styles with a clear naming convention:
heading/h1: 36px / Bold / line-height 1.2heading/h2: 30px / Bold / line-height 1.25heading/h3: 24px / Semibold / line-height 1.3body/lg: 18px / Regular / line-height 1.6body/md: 16px / Regular / line-height 1.6body/sm: 14px / Regular / line-height 1.5label/md: 14px / Medium / line-height 1.4label/sm: 12px / Medium / line-height 1.4
Apply your color/text/primary and color/text/secondary Variables to text fills so typography automatically adapts between Light and Dark modes.
Step 4 — build your first five components
With tokens defined, build components in this specific order. Each builds on patterns from the previous one.
Component 1: Button
Build a single button component with these variant properties:
- Variant: Primary, Secondary, Outline, Ghost, Destructive
- Size: SM, MD, LG
- State: Default, Hover, Disabled
Use Auto Layout with space/3 (12px) vertical padding and space/4 (16px) horizontal padding for Medium size. Apply color/brand/primary for the Primary variant fill. Apply radius/md for border-radius.
Every visual property references a Variable. No hardcoded hex values. No raw pixel numbers.
Component 2: Input
Text input with label, placeholder, helper text, and error state. Same spacing tokens as Button for padding consistency. Use color/border/default for the border, color/status/error for error state border, color/text/secondary for placeholder and helper text.
Component 3: Card
Container component with color/bg/surface background, color/border/default border, radius/lg border-radius, and space/5 (20px) padding. Build it flexible — Card is a layout primitive, not a specific pattern. It should hold any content.
Component 4: Badge
Status indicator using semantic color tokens. Variants for Success, Warning, Error, Info, Neutral. Each variant maps directly to your color/status/* tokens. This tests whether your token architecture handles status colors cleanly.
Component 5: Dialog
Overlay with backdrop, surface card, heading, body text, and action buttons. Dialog assembles from existing tokens and components — Card for the container, Buttons for actions, your text styles for heading and body. If your token architecture is sound, Dialog comes together naturally. If something fights you, the token structure needs adjustment.
Step 5 — dark mode in one click
If you followed steps 1–4 with tokens applied to every visual property, dark mode already works. Open the Figma Variables panel, switch the mode from Light to Dark, and every component updates automatically.
This is the payoff. Dark mode is not a redesign — it is a mode switch that takes zero additional design effort because all visual properties reference semantic tokens with different values per mode.
Debugging dark mode: If elements do not switch properly, they have hardcoded values bypassing the token system. Select the element, check its fill/stroke/text color — if it shows a hex value instead of a Variable reference, replace it with the appropriate token. This debugging pass typically takes 30–60 minutes and reveals every place where discipline slipped.
Step 6 — export tokens for development
The W3C Design Tokens v1.0 specification standardizes the format for sharing tokens between design tools and code. Install the Tokens Studio for Figma plugin (free tier) to export your Variables as W3C DTCG-format JSON.
This JSON file becomes the single source of truth that both Figma and your codebase reference. The development team consumes tokens through Style Dictionary or Cobalt, which generates platform-specific code — CSS custom properties, Tailwind config, iOS Swift, Android XML.
The specifics depend on your tech stack, but the principle is universal: design decisions live in tokens, both design and code read from the same token file, and a change in one place propagates to both.
Keeping it alive — the minimum governance that prevents the 60% failure rate
Design systems fail because nobody maintains them after the initial build. According to the 2024 Sparkbox Design Systems Survey, teams with dedicated governance reported 2.5x higher satisfaction than those without. But you do not need a dedicated team — you need a lightweight cadence.
Weekly (30 minutes): One designer reviews recent work for hardcoded values or detached component instances that bypass the system. Fix drift before it compounds.
Monthly (1 hour): The team discusses whether new patterns have emerged that should become components. The rule: add a component only when a pattern has appeared three or more times in production work. Premature abstraction kills systems faster than missing components.
Quarterly (half day): Audit token values in Figma against the live codebase. Are they still in sync? Has development introduced values that do not exist in the token file? Fix drift while it is still manageable.
This is the governance minimum. It is not exciting. It is not innovative. It is what separates design systems that survive from design systems that become beautiful, unused artifacts.
Frequently asked questions
How do I create a design system in Figma from scratch?
Start with Figma Variables for color, spacing, and radius tokens — not components. Define a two-tier token architecture: primitives (raw color values) and semantics (what colors mean in context). Then build five core components (Button, Input, Card, Badge, Dialog) with every visual property referencing tokens. Dark mode comes free when all properties use semantic tokens. Full step-by-step process in this guide.
What are Figma design tokens and how do they relate to Variables?
Figma Variables are Figma's implementation of design tokens — reusable named values (colors, numbers, strings) that can change based on context like Light and Dark modes. The W3C Design Tokens specification (v1.0, October 2025) standardizes how tokens are shared between design tools and code. Figma Variables can be exported as W3C DTCG-format JSON through the Tokens Studio plugin.
Can a small team or solo designer build a design system?
Yes — and a focused system from a small team often outperforms an ambitious system from a large one. The token architecture and five components described in this guide can be built by one designer in a weekend. The key is starting with tokens (not trying to build 100 components), applying consistent governance, and adding components incrementally as real project needs demand them.
Why do 60% of design systems fail?
Three primary causes: overambition (building 200 components before shipping any value), lack of governance (nobody maintains the system after launch, so it drifts from production reality), and poor token architecture (hardcoded values that make systematic updates impossible). The token-first approach in this guide prevents the third cause. The "build five components and ship" approach prevents the first. The weekly/monthly/quarterly governance cadence prevents the second.
How do I export Figma Variables as design tokens for developers?
Install the Tokens Studio for Figma plugin (free tier). It exports your Variables as W3C DTCG-format JSON — the standardized token format adopted by the industry. Developers consume this JSON through Style Dictionary, Cobalt, or custom pipelines that generate CSS custom properties, Tailwind config, or platform-native code. The exported file becomes the single source of truth for both design and development.
What is the difference between Figma Variables and Styles?
Variables store individual values (a single color, a number, a string) and support modes (Light/Dark). Styles store combinations of properties (a text style combines font family, size, weight, line-height, and color). Use Variables for tokens that need mode-switching capability. Use Styles for typography combinations and complex effects like shadows. As Figma expands Variable types, the overlap will increase — but for now, you need both.
[Find design system tools, token managers, and Figma resources → Mantlr](https://mantlr.com)
Written by [Author Name], a product designer building [Mantlr](https://mantlr.com) — a curated resource directory for designers and developers.