September 23, 2025

How to Build a Design System in Figma—The Right Way

A product designer’s guide to tokens, variables, and scaling without chaos

What makes a design system usable isn’t just consistency, it’s clarity. And what makes it scalable? Structure.

Figma gave us variables. But a real system isn’t just modes and colour ramps, it’s a design API. If you don’t build it like a product, it breaks like a file.

Without structure, your system is just a scattered collection of styles in denial.

Here’s how to build a system that actually holds up: token-powered, developer-friendly, themeable, maintainable, and future-ready.

(If you’re setting up your first system, the next sections will be tactical. If you’re already scaling, skip to governance, contribution, and measurement.)

🧠 Start with System Thinking, Not Styles

Good systems start with shared context, not auto layout.

Ask:

What platforms will this system support? Web? iOS? Android? AR?
Do we need light/dark modes, multibrand themes, or just flexible defaults?
What should stay flexible? What needs to be locked?

This isn’t just a file structure, it’s a shared mental model.

🔹 Tokens & Variables: A System’s Real Infrastructure

Forget the style panel. The real power is in how you structure your tokens:

Primitives: Raw values like #E91E63, 16px, 100% (not used directly)
Semantics: Contextual names like button/primary/bg or text/heading/default
Components: Specific mappings like btn/hover/fill, often used at handoff
Variables: Figma’s system for assigning values across light/dark modes, themes, and collections

Together, these form the programmable foundation for every layout, theme, and interaction.

🧱 Step 1: Define Your Primitives

These are your bricks. Be consistent. Be boring. Be brilliant.

Colour: Ramps like mocha/10, lavender/50, obsidian/90
Spacing: Stick to base-4 or base-8: space/4, space/8, etc.
Type: Use text styles like text/header/h1, text/paragraph/small

If you’re using Figma’s Variables, primitives go in a dedicated collection. Don’t mix levels.

🎨 How to Build a Colour Ramp (Without Cheating with Opacity)

Stop using transparency for ramp values. That’s not theming—it’s math cosplay.

Why you shouldn’t use transparency:

It breaks across themes
Contrast fails accessibility checks
Devs can’t implement it reliably

What to do instead:

Use tools like Leonardo or OKLCH Picker
Create fully opaque steps with proper hex codes
Test for accessibility with Stark or Able

🧠 Step 2: Alias Semantics

This is where structure becomes strategy.

Create semantic tokens that point to your primitives:

button/primary/bg → mocha/70
text/heading → obsidian/100
card/surface → powder/20

Then create modes (light/dark/brand) that switch the primitives beneath.

Pro tip: Use semantic tokens for flexibility. That’s how you swap themes or brands without touching components.

🧩 Step 3: Apply to Components

Every component should be powered by tokens—not raw values.

✅ Good: button/primary/bg

❌ Bad: #0055FF, 24px

Combine with:

Variants → for interaction states
Auto Layout → for flexibility
Variables → for instant theming

This is how you make a button that adapts without extra logic.

♿ Bake in Accessibility

Accessibility shouldn’t be a checklist, it should be in the DNA.

Use tokens for:

Minimum contrast pairings
Spacing that supports 44px touch targets
Minimum font sizes for legibility

Validate with plugins like Stark, Able, or built-in contrast checks.

🔌 Variables vs Tokens Studio: Which Should You Use?

Figma Variables (native):

Great for modes, themes, collections
Smooth Dev Mode integration
Limited to colours, numbers, booleans

Tokens Studio (plugin):

Supports typography, shadows, borders
Exports to CSS, JSON, iOS, Android
Syncs with GitHub for dev parity

Use both if you can. Variables for Figma logic. Tokens Studio for cross-platform code delivery.

🌀 Versioning, Docs & Changelogs

This is where you graduate from “system” to “product.”

Use Figma Branching to test updates
Keep a changelog in Notion, FigJam, or GitHub
Define owners for every token collection
Don’t just store components, explain how and when to use them

If it’s not documented, it’s not a system. It’s a style guide in denial.

✅ Design System Health Checklist

Foundation

✅ Primitives defined (colour, spacing, type)
✅ Naming conventions clear
✅ Collections structured

Design

✅ Semantic tokens aliased
✅ Variants + auto layout applied
✅ Tokens used in all components

Themes & Modes

✅ Light/dark modes live
✅ Consistency tested across contexts

Code Handoff

✅ Tokens exported via plugin/tooling
✅ Design/code parity confirmed

Governance & Docs

✅ Documentation in Figma
✅ Changelog maintained
✅ Ownership and proposal process in place

⬇️ Download “Meridian” — My Starter Design System

Meridian is my starter design system—free, modular, and set up the way I’d build it inside a Fortune 100 product org.

It includes:

A full token architecture (primitives → semantics → components)
Light/dark theming
Trending 2025 colour palette: Navy, Mocha, Lavender, Verdant, Sunny, Terracotta, Obsidian, Powder
Developer-friendly variable structure
Ready-to-use components powered by semantic tokens

Start With Meridian

My free Figma starter kit with tokens, scales, and components built for clarity. Use it as your foundation to design at scale.

Try It Free

🧰 Tools to Help You Build Faster

🎨 Foundation: Colour Generator – Auto-generate accessible, themeable colour ramps
🔡 Typescales – Create modular typography hierarchies (H1–H6, captions, subtitles)
🆔 Figr Identity – Generate coherent type and colour systems for branding foundations
🛁 Design Lint – Easily cleanup and reorganize giant design systems

🌐 Future-Proofing Your System

Guiding Principles – Values like “Accessible by default” or “Brand at scale” resolve debates before they start.
Pattern Libraries – Include documented flows like onboarding, modals, and navigation—context matters.
Adopt, Adapt, or Create? – Don’t reinvent the wheel unless it gives you traction. Start with Polaris, Carbon, or Fluent if needed.
AI Integration – Use AI tools to auto-generate docs, tokens, or component variants.
Contribution Models – Set up proposal flows in FigJam. Approve, version, publish—like open-source.
Cross-Platform Readiness – Web, iOS, Android, and AR/VR should all be token-compatible.
Success Metrics – Track adoption, system usage, time saved, or support tickets reduced.
Change Management – Roll out changes with intent. Pilot, train, communicate.
Inspiration Sources – Study Material, Polaris, Fluent, Spectrum—and steal structure, not visuals.

🧠 Final Thoughts

Figma didn’t just give us a better way to name colours. It gave us a design API.

And like any API, the best systems aren’t built to look good. They’re built to scale, evolve, and ship faster with trust.

If you treat your design system like a product—not a file—it won’t just survive growth. It’ll accelerate it.

Scaling a system right now? I’d love to hear what challenges you’re facing. Connect with me on LinkedIn, I’m collecting real patterns from systems in the wild.