How I build scalable design systems from scratch

A design system isn’t a component library. It isn’t a style guide. It isn’t a Figma file full of buttons. It’s a living, structured agreement between design and development about how your product looks, feels, and behaves — and when it’s built well, it scales with you instead of against you.

I’ve built design systems from scratch, and the biggest mistake I see is teams jumping straight to components. Components are the last thing you should be building. Here’s how to actually do it right.

Start with primitives

Primitives are the raw values that everything else is built on. Think of them as your design atoms — they have no semantic meaning yet, they just exist as a source of truth.

Your primitive tokens should cover:

• Color — every hex value your brand uses, named neutrally. Not “primary blue” — just “blue-500”, “blue-600”, and so on.
• Typography — your font families, weights, and a type scale
• Spacing — a consistent scale (4px base works well) that governs padding, margins, and gaps throughout the UI
• Border radius, shadow, and motion — anything that gets reused across components

At this stage you’re just naming and organizing raw values. No decisions about where they’re used yet.

Build the semantic layer

This is where most design systems skip a step and pay for it later.

Semantic tokens give meaning to your primitives. Instead of applying “blue-500” directly to a button, you create a token called “color-action-primary” that references “blue-500.” Now if your brand color changes, you update it in one place and it cascades everywhere.

A solid semantic layer covers:

• Surface colors — backgrounds, cards, overlays
• Text colors — default, muted, inverse, on-color
• Interactive colors — default, hover, active, disabled states
• Feedback colors — success, warning, error, info
• Border and focus styles

If you’re working in Figma, this is where variable collections with modes become incredibly powerful — you can wire your semantic tokens to both a light and dark mode from the start.

Define the typography system

Before you build a single text component, document your type decisions:

• What font families are you using and why?
• What is your type scale? (I recommend a modular scale — it creates natural visual hierarchy)
• What are your named text styles? (display-xl, heading-2xl, body-md, label-sm, etc.)

Name your styles by role and size, not by appearance. “Display text large” tells you what it’s for. “Big bold serif” tells you nothing useful when you’re six months into the project.

Build the component library

Now — and only now — you build components. With your token foundation in place, every component you create is already wired to your system. Changing a semantic color token updates every component that references it simultaneously.

Build components in order of dependency:

1. Base elements — buttons, inputs, labels, icons
2. Compound components — form fields (label + input + helper text), cards, modals
3. Layout components — grids, containers, navigation
4. Page-level patterns — hero sections, feature blocks, footers

Document every component with its variants, states, and usage guidelines. A component without documentation is just a shape.

Write usage guidelines

This is what separates a design system from a component library. Guidelines answer the questions your future self — or a future team member — will have:

• When do I use this component vs. that one?
• What should never go in this component?
• What accessibility requirements does this component have?
• What are the responsive behaviors?

Even if you’re a solo designer right now, write the guidelines. Systems are for scale, and scale means other people eventually.

Treat it like a product

A design system is never finished. It needs versioning, documentation, and a process for adding, deprecating, and updating components over time. The most successful systems I’ve seen are ones where someone took ownership — not just of building it, but of maintaining it.

Audit it regularly. Does every component still align with your semantic tokens? Have any one-off styles crept into your product that need to be systematized? Is your documentation still accurate?

The goal isn’t perfection at launch. The goal is a foundation solid enough that every decision you make on top of it is easier than the last.