Building a design system from zero to one
Build a design system from zero by auditing existing screens, defining foundations (colour, type, spacing) as tokens, building a small set of high-use components, documenting usage, and piloting it on one product before scaling. Treat it as a product with owners, a roadmap and feedback from the teams who use it.
Why start a design system
Most products reach a point where inconsistency starts to slow everyone down. Designers create slightly different buttons for each new screen, developers rebuild the same components in different ways, and the product gradually looks less coherent. Every new feature takes longer than it should because nothing can be reused with confidence. A design system addresses this by providing a shared set of foundations, components and guidelines that everyone builds from.
Starting a design system can feel daunting, especially when you look at the large, mature systems published by major technology companies. But those systems did not start that way. They began with a few foundations and core components, then grew as teams used them. This guide explains how to get from nothing to a first useful version, which we call going from zero to one. For scaling a mature system across a large organisation, see our enterprise design systems guide.
The four phases
- Audit: Collect every button, colour and pattern in use and spot duplicates.
- Foundations: Define colour, type, spacing, radius and elevation as tokens.
- Core components: Build the most-used pieces: buttons, inputs, cards, navigation, modals.
- Pilot and scale: Use it on one product, gather feedback, then roll it out.
Running the interface audit
The audit is the foundation of the whole system. Take screenshots of every screen in the product, or at least the most used ones, and collect them in a shared board. Then group similar elements together: all the buttons, all the form fields, all the colours, all the text styles. Most teams are surprised by what they find, such as dozens of shades of the same brand colour or many slightly different button styles. These duplicates show exactly where a system will save time.
| Element | What to collect | Typical finding |
|---|---|---|
| Colours | Every colour used in the interface | Many near-identical shades |
| Typography | Every font size, weight and line height | Too many sizes with no clear scale |
| Buttons | Every button style and state | Several primary styles |
| Forms | Inputs, selects, checkboxes, errors | Inconsistent labels and error messages |
| Spacing | Margins and padding values | Random values with no system |
Defining foundations and tokens
Foundations are the basic visual decisions that every component builds on. Define a colour palette with clear roles, such as primary, secondary, background, text, success, warning and error. Create a type scale with a limited number of sizes and weights. Set a spacing scale, often based on multiples of four or eight pixels, and define corner radius and shadow levels. Store all of these as design tokens, named values that can be shared between design tools and code, so a change in one place updates everywhere.
- Colour tokens: Named by role, such as color-text-primary or color-surface.
- Type tokens: A clear scale, such as heading-1 to body-small.
- Spacing tokens: A consistent scale, such as 4, 8, 12, 16, 24 and 32.
- Radius and elevation: A few options used consistently across components.
What to include in version one
| Layer | Include first | Add later |
|---|---|---|
| Foundations | Colour, type, spacing tokens | Motion, illustration |
| Components | Button, input, select, card, modal | Data tables, charts |
| Patterns | Forms, empty states, errors | Onboarding, dashboards |
| Docs | Usage rules and do/don’t examples | Contribution guide |
Building the first components
Choose the first components based on the audit and on what teams use most. Buttons, text inputs, selects, checkboxes, cards, modals and navigation usually cover a large part of most products. For each one, design every state, including default, hover, focus, active, disabled, loading and error, and build it in code at the same time. Building design and code together keeps them in sync from the beginning and avoids the common problem of a design library that does not match production.
- Design: Create the component and all its states in the design tool.
- Review: Check accessibility, responsiveness and edge cases.
- Build: Implement the component in code using the same tokens.
- Document: Add usage guidance and examples.
- Release: Publish it and announce it to the teams.
Lessons from building systems
- Start small: A useful small system beats a perfect one that never ships.
- Code and design together: Keep design files and code components in sync from day one.
- Accessibility built in: Contrast, focus and labels baked into every component.
- Measure adoption: Track how many screens use system components.
For scaling across large organisations, read our enterprise design systems guide. Building accessibility into components from the start saves rework later.
Piloting the system
Before rolling the system out everywhere, test it on one real project. A pilot shows where components are missing, where documentation is unclear and where the system does not fit real needs. Work closely with the pilot team, fix problems quickly and use their feedback to improve the system. A successful pilot also produces a strong example that other teams can see, which makes adoption much easier. Our post on design systems that teams actually use covers how to grow adoption after the first version.
Frequently asked questions
How long does a first design system take?
A focused first version with foundations and core components usually takes six to twelve weeks.
Do small teams need a design system?
A lightweight one helps even small teams stay consistent and build faster.
Which tools are used for design systems?
Commonly Figma for design, a component library in code, and documentation tools such as Storybook or zeroheight.
Should we start with design or code?
Both together. Designing and building each component at the same time keeps the design library and production code in sync.