Building a Design System from Zero to Production

A design system is not a component library. That distinction sounds pedantic until you've watched a team build a component library that no one uses. Components without shared decisions behind them are just a collection of buttons and inputs. A design system is a shared language — visual, structural, and semantic — that lets designers and engineers make consistent decisions independently, without a meeting every time someone needs a new modal.

Here's how we approach building them, from a blank Figma file to something that ships.

Phase 1: Audit before you design

If you're building for an existing product, start with a full UI audit. Screenshot every screen. Count how many different button styles exist. Count how many shades of gray are used for body text. The number is always higher than the team thinks — usually 3x higher. We've done audits on products that had 14 distinct button variants and 8 different heading sizes, none of them on a consistent scale.

The audit isn't about embarrassing anyone. It's about understanding what's already doing real work in the interface — patterns that users are already habituated to — versus what's pure inconsistency that creates cognitive noise. Not everything in the audit gets cleaned up in v1. You're building a map before you start drawing new roads.

Phase 2: Establish the foundation before touching components

Most teams jump straight to building components. This is the wrong order. Before you design a single button, you need to lock in:

• Color tokens — not palette colors, but semantic tokens. Not blue-500, but color-action-primary and color-feedback-error. The semantic layer is what lets you retheme without rebuilding.
• Type scale — a small number of sizes (usually 5–7) with defined line-height and letter-spacing at each step. This scale should be expressed in design tokens, not pixel values.
• Spacing system — a consistent spacing scale, usually 4px-based. Every margin, padding, and gap in the system comes from this scale.
• Elevation model — how many surface levels exist, what shadow treatment each gets, and when each is used.
• Border radius conventions — one or two radius values, applied consistently.

Getting the foundation wrong is expensive. Getting it right makes everything downstream much faster.

Phase 3: Build components in layers

We build components in three layers: primitive, composite, and pattern. Primitives are the atoms — buttons, inputs, badges, icons. Composites are built from primitives — a search input is a primitive text field plus a primitive icon button inside a composite wrapper. Patterns are full UI solutions — a data table with sorting and pagination, a form with validation states, a multi-step wizard.

The goal at each layer is the same: make the right thing easy and the wrong thing require deliberate effort. A button with the wrong variant should feel awkward to use — not impossible, but clearly off-pattern.

For each component, we document five things: the intended use case, the props API, all interactive states (default, hover, active, focus, disabled, loading, error), responsive behavior, and accessibility requirements. If you can't document it, you haven't designed it well enough yet.

Phase 4: The engineering handoff that actually works

Design system handoffs usually fail for one of two reasons: the components are over-specified (so engineers have to ask questions about every edge case) or under-specified (so engineers make divergent implementation decisions that erode the system over time).

The handoff format we've found most effective is a Storybook with co-located documentation. Each component story shows all variants, all states, and all prop combinations. The documentation explains not just how to use the component but why it exists — what design decision it encodes and when you should reach for something else instead.

The most important thing in the handoff is the decision log. For every non-obvious decision — why the button radius is 8px and not 6px, why there are only two button sizes instead of three — there's a one-line note. This doesn't have to be elaborate. But it prevents the “why is it like this?” questions that erode confidence in the system.

Phase 5: Governance that scales without bureaucracy

A design system that's too rigid gets forked. A design system that's too permissive drifts back into inconsistency within months. The governance model we recommend is a simple two-track system: a fast track for bug fixes and small additions (one designer review, ships with the next release cycle) and a deliberation track for new components or breaking changes (requires both design and engineering sign-off, documented rationale).

Most importantly: treat the design system as a product. It has users (your designers and engineers), it needs maintenance, and it needs someone whose job it is to care about it. A design system that's “owned by everyone” is owned by no one.

What a mature design system actually looks like

At full maturity, a design system does something that's hard to describe until you've experienced it: it removes a whole category of decisions from the design process. Designers stop arguing about button heights. Engineers stop asking which shade of gray to use for a disabled state. Product discussions stop getting stuck on visual details and focus on the actual product questions. That's the payoff — not a beautiful component library, but a team that can move faster and stay coherent at the same time.