Design Systems: Where to Start

Most teams that decide to build a design system already have a product in production. There are forty screens, three button styles that were meant to be one, and a color palette that grew a new gray every quarter. The question they actually face is which piece to standardize first, with a product that has to keep shipping while they do it.

This guide covers that order of work: what to audit, which tokens and components come first, how much documentation is enough to begin, who owns the thing, and what tools you need at each stage. For the definition itself and the full list of layers, see the design systems hub.

What is a design system, in one paragraph

A design system is the set of shared decisions a team uses to build one coherent product: design tokens (color, spacing, type, radius), the components built from them, the patterns that combine components into common screens, the written guidance on when to use what, and the process for changing any of it. A component library is one part of that. A Figma file of styles is another part. Neither is the whole system, because neither says who decides when a new variant is allowed. NN/g's Design Systems 101 uses a similar breakdown.

Start with an interface inventory

Before designing anything new, collect what already ships. Take screenshots of every distinct button, input, heading style, color, card and modal in the production product, and group them by type in one board. Brad Frost called this an interface inventory, and it's still the fastest way to get a team to agree there's a problem.

The inventory usually shows two things:

• Duplicates that differ by accident. Four blues within a few percent of each other, or buttons with 6, 8 and 10 px corner radius. These are free wins, since collapsing them changes nothing a user would notice.
• Differences that carry meaning. A red button that means "destructive" and a red button that's red because a marketing page needed contrast. These need a decision, and the decisions become your first guidelines.

Record counts, not just examples. "We ship 11 button variants" is an argument you can take to a roadmap meeting, and after the first release you can measure against it.

Define tokens before components

Tokens are the named values everything else refers to: color.text.primary, space.4, radius.medium, font.size.body. Define them before building components. A component built on hard-coded hex values has to be edited by hand every time the palette changes, while one built on tokens picks up the change automatically.

Start with four groups:

1. Color, split into a base palette (blue.500) and semantic roles (color.action.primary, color.border.subtle). Components should reference the roles. The palette can change underneath them, which is what makes dark mode and rebrands manageable.
2. Spacing, on a fixed scale, usually multiples of 4 or 8 px. Seven or eight steps cover most products.
3. Typography, as a type scale with named roles (display, heading, body, caption), each with size, line height and weight. Choosing fonts covers how to set the scale itself.
4. Radius and elevation, which are small sets but show up on every surface.

Keep token names in one format that both design and code tools can read. The W3C Design Tokens Community Group format is the common choice, and most token tools import and export it.

Build the five components you rebuild most

Don't try to build a full library before anyone uses it. Look at the inventory and pick the components that appear on the most screens and have the most accidental variants. That list is some version of:

• Button
• Text input (with label, help text and error state)
• Select or dropdown
• Modal or dialog
• Card or list row

Build each one completely before moving on: every state (default, hover, focus, disabled, loading, error), keyboard behavior, and accessible labels. Ship the five into the real product, replace the old versions on at least one live flow, and fix what breaks. That first migration shows you where the component API is wrong much faster than any review of the Figma file.

Patterns (a sign-up form, an empty state, a confirm-before-delete flow) come after the components they're made of. User interface design principles covers the principles those patterns should encode.

Write the documentation people will actually read

Design system documentation is where most early efforts overbuild. A team spends a quarter on a documentation site with a hero section and a changelog, and adoption doesn't move, because the components didn't exist yet.

For the first release, each component page needs four things:

• What it's for, in one or two sentences.
• When not to use it, with the component to use instead. This is the part that prevents the most misuse.
• Its variants and states, shown as rendered examples.
• Content rules, such as button label length or capitalization. Sentence case vs title case is a typical rule to settle here once instead of in every review.

Put the docs where people already work. That's Storybook next to the code and a page in the Figma library, before a separate site. A standalone documentation site starts paying off once several teams consume the design system and need a single link to share.

Decide who owns the design system

A design system without an owner drifts back toward the inventory you started with. Someone has to decide whether a new variant gets added or turned down, and someone has to review changes to tokens.

Nathan Curtis's widely cited team models give three basic shapes:

• Solitary. One product team builds the system for its own use and others may copy it.
• Centralized. A dedicated team builds and maintains the system for everyone.
• Federated. Designers and engineers from several product teams contribute, with a small core group that reviews.

Most companies start solitary, whether or not they call it that. What matters early is writing down the contribution rule: how someone proposes a new component or variant, who reviews it, and how long a review takes. Public systems like the GOV.UK Design System publish their contribution process, and it's worth reading one before you write your own.

Design system tools by stage

You need fewer tools at the start than tool roundups suggest.

Stage	What you need	Common choices
Inventory	A board to collect and group screenshots	Figma, FigJam, Miro
Tokens	One source of truth that exports to code	Figma variables, Tokens Studio, Style Dictionary
Components	A shared design library and a coded component package	Figma libraries, React/Vue/Web Components, Storybook
Documentation	Pages next to where people build	Storybook docs, Zeroheight, Supernova
Governance	A place to propose and track changes	GitHub issues, Linear, Jira

A design system management tool (Zeroheight, Supernova, Knapsack and similar) becomes worth paying for once several teams rely on the system and need documentation, token sync and versioning in one place. Before that, a Figma library, a Storybook and a README carry most teams through the first year.

Common mistakes in the first six months

Starting from a style guide nobody asked for. A system designed in isolation and presented finished gets polite approval and little use. Build it from the inventory and migrate real screens early.

Naming tokens after values. blue-light stops being accurate the day the brand color changes. Name semantic tokens after their job, like color.surface.info.

Treating consistency as the goal. A design system makes it easy to assemble correct-looking screens. They can still be confusing if the patterns underneath were never tested with users. The design systems hub goes into how a mature system can wear down clarity when nobody checks what the components add up to.

Measuring output instead of adoption. The number of components built says little. Track the share of production screens using system components, and the number of one-off overrides.

Frequently asked questions

How do you create a design system from scratch?

Inventory what ships, define tokens, build the few components you rebuild most, migrate one real flow onto them, then document and assign an owner, in the order the sections above lay out.

How long does it take to build a design system?

A usable first version, meaning tokens, five to ten components in production and basic docs, takes a small team one to three months alongside regular product work.

When is a team too small for a design system?

A solo designer working with one or two engineers can get most of the benefit from shared tokens and a small component library in code. The governance layer starts to matter once more than one team builds UI, or once the same component is rebuilt a second time.

Should you use an existing design system instead of building one?

Often, yes. Material Design, Carbon, Fluent and similar open systems give you tested components and accessibility work for free. The trade-off is that your product looks like everyone else's until you theme it through the tokens. Many teams start on an open system and replace pieces as their needs diverge.

What should design system documentation include?

The four items listed under documentation above, plus code usage and accessibility notes for engineers.

What are the best design system tools?

It depends on the stage; the tools table above lists common choices for each one.

Sources: NN/g — Design Systems 101 · Brad Frost — Atomic Design, Chapter 4 · Design Tokens Community Group — Format · GOV.UK Design System.