This is the build order we use for new design systems. It's optimised for getting to "the system is actually being used" as quickly as possible — not for completeness.

Step 1: Start with tokens

Before you design a single component, lock down your tokens:

  • Colours. Primitive palette (named after the colour itself, e.g., blue-500) and semantic tokens (named after the purpose, e.g., action-primary). Components reference semantic tokens.
  • Typography. Type scale, font families, weights, line heights. Six-eight scale steps maximum.
  • Spacing. A geometric scale (4, 8, 12, 16, 24, 32, 48, 64). Avoid arbitrary spacing values.
  • Radii. Three to five values.
  • Motion. Duration and easing tokens.

Step 2: Build the token pipeline

Tokens live in a source file (we use JSON or TypeScript). A build step compiles them to:

  • CSS custom properties for the web codebase.
  • Figma variables (importable via Figma Tokens or Variables API).
  • iOS / Android constants if relevant.
  • TypeScript types for autocomplete.

This is the single most important investment you'll make. Drift is impossible if there's one source of truth.

Step 3: Primitives before components

Build primitives before you build "components":

  • Layout primitives. Stack, Inline, Grid, Cluster — components that handle spacing and alignment.
  • Text primitives. Heading, Body, Caption — components that wire type tokens to semantic HTML.
  • Icon primitive. A single Icon component that takes a name prop.

With these primitives, you can compose 80% of what marketing-site designers and product designers want to build.

Step 4: The first ten components

Build these ten before you build anything else:

  1. Button (with variants)
  2. Input (text, with states)
  3. Select / Combobox
  4. Checkbox and Radio
  5. Card
  6. Tooltip
  7. Modal / Dialog
  8. Toast / Notification
  9. Tabs
  10. Avatar

This set covers 70% of UI patterns. Build them right, document them, get them adopted. Then expand.

Step 5: The Figma mirror

The Figma library mirrors the code library 1:1. Same names, same variants, same props. Designers in Figma should be able to map any choice they make directly onto a code prop.

Step 6: Documentation

Docs live in the same repo as the components. Generated from JSDoc + Storybook + MDX. One CI run, one deploy, one source of truth.

Step 7: Ownership

Someone owns the system. Their name is on the README. They run weekly office hours. They review every proposed addition. Without ownership, the system dies within 18 months — guaranteed.

Step 8: Adoption strategy

Don't try to migrate everything at once. Start with the highest-traffic surface, build credibility with one visible win, then expand. Track adoption as a percentage of pages/screens using exclusively system components. Report it weekly.

What to avoid

  • Don't ship a "complete" system before anyone uses it. Ship 10 components, iterate.
  • Don't over-specify behaviour in docs. Tests and code are the source of truth.
  • Don't accept random product team additions without review. The system needs a gatekeeper.
  • Don't conflate the design system with branding. The system is the chassis; branding is the paint.