A design system is not a Figma file full of buttons. It is an agreement — between designers, engineers and the product — about what things look like and how they behave. The file is just where the agreement is written down, and the code is where it is enforced.
This is our primer for founders and product leads. It covers what a design system contains, when you actually need one, how design tokens make it work, how to keep design and code from drifting, and a realistic plan for building your first one without stopping feature work.
What is a design system?
Nielsen Norman Group defines a design system as a complete set of standards for managing design at scale, made of reusable components and patterns (Design Systems 101). In practice, a working design system for a startup has four layers:
| Layer | What it contains | Who owns it |
|---|---|---|
| Foundations | Colour, type scale, spacing, radius, elevation, motion — as tokens | Design, with engineering sign-off |
| Components | Buttons, inputs, modals, tables, navigation — designed and coded | Shared: one source per component |
| Patterns | Forms, empty states, onboarding, error handling | Product design |
| Guidelines | Usage rules, do and don't examples, accessibility notes, voice | Everyone, kept in one place |
Large public examples — Google's Material Design 3 and the U.S. Web Design System — show what the mature version looks like. You do not need that scale on day one. You need the same structure, sized to your product.
When your product needs a design system
The moment you ship a second surface. A marketing site and an app. An admin panel and a customer dashboard. The day two teams build the same modal differently is the day a design system would have paid for itself.
- Two or more products or surfaces share users and brand.
- The same component is built twice with slightly different spacing, colours or behaviour.
- Design review turns into pixel debates instead of product decisions.
- New engineers ask "which button do I use?" — and get three answers.
- A rebrand or dark mode is on the roadmap and feels impossible to do safely.
Signs you do not need one yet
A pre-launch product with one surface and one designer rarely needs a full design system. What it does need is the foundation: a small set of named colours, a type scale and a spacing scale, used consistently. That is a day of work, and it means the system can grow out of real product needs later instead of being designed in the abstract.
Design tokens: the layer that makes it work
Colours, spacing, type and radius should be named values, not hex codes scattered across the codebase. That is what design tokens are — and there is now a community specification for them from the W3C Design Tokens Community Group, so tools can share them.
We use three layers. Change one semantic token and every button on every product updates, without anyone hunting through stylesheets:
| Token layer | Example | Rule |
|---|---|---|
| Primitive | blue-600, space-4, radius-2 | The raw palette and scale. Never used directly in components. |
| Semantic | color-action, surface, text-muted | Meaning-based aliases. This is what designers talk about. |
| Component | button-background, input-border | The few values one component needs, mapped from semantic tokens. |
Semantic tokens are also how dark mode, white-labelling and rebrands become configuration rather than a rewrite: you remap the semantic layer and leave components untouched.
Design and code must not drift
A design system that lives only in Figma is a suggestion. Every component we design has a coded twin in Storybook, and visual regression tests catch the moment they diverge. When designers and engineers look at the same source of truth, review meetings get very short.
- One component, one source. The coded component is the truth; the design file mirrors it.
- Tokens flow one way. Export them from the design tool into code automatically, never by copy-paste.
- Review in the browser. Sign off components in Storybook, not in static mock-ups.
- Automate the check. Visual regression tests flag unexpected changes on every pull request.
Accessibility belongs inside the system
The single biggest return from a design system is that accessibility gets solved once. Colour contrast, focus states, keyboard navigation and screen-reader labels are built into each component, so every screen that uses it inherits them. Build against the Web Content Accessibility Guidelines (WCAG) from the start; retrofitting them across a product is far more expensive.
What a design system pays back
The return shows up in places founders feel directly. Features ship faster because engineers assemble screens from finished parts instead of building each one from scratch. Design review moves from pixel debates to product questions. Onboarding a new designer or engineer takes days instead of weeks, because the rules are written down. And brand changes stop being projects.
| Without a design system | With a design system |
|---|---|
| Each screen styled by hand | Screens assembled from tested components |
| Three versions of the same modal | One modal, used everywhere |
| Accessibility fixed screen by screen | Accessibility fixed once, inherited everywhere |
| A rebrand means touching every file | A rebrand means remapping semantic tokens |
| New hires learn by asking around | New hires learn from the documentation |
Documentation is the product
Usage rules, do and don't examples and accessibility notes are what turn a component library into a design system. Without them, every engineer reinvents the guidance — usually wrong. Write the docs as if the reader joined yesterday, because someone always did.
Keep documentation next to the components, not in a separate wiki nobody opens. The same principle runs through our remote collaboration tools: fewer places to look, one source of truth.
How to build your first design system without stalling
The failure mode is treating it as a separate project that pauses the roadmap. Build it inside feature work instead:
- Audit what exists. Screenshot every button, input and modal in the product. The duplicates are your backlog.
- Define foundations as tokens. Colour, type, spacing and radius first — a week of work that unlocks everything else.
- Extract the top ten components the next features will use, and build them properly once.
- Migrate screens as you touch them. Every feature that ships leaves its screens on the system.
- Assign an owner. Someone must approve new components, or the system forks again.
For a view of this at larger scale, our case study on one design system across four products walks through the approach. Our UI/UX and product design team builds systems this way — tokens, coded components and docs together.
Consistency is not about sameness. It is about never making the user re-learn your product.
If your product has started to look like three products stitched together, talk to us. We will tell you honestly whether you need a full design system yet, or just a set of tokens and ten good components.
Frequently asked questions
What is a design system in simple terms?
A shared set of rules and reusable pieces — colours, type, spacing, components and usage guidelines — that designers and engineers both use, so every screen of a product looks and behaves consistently.
What is the difference between a design system and a style guide?
A style guide documents visual rules such as colours, logos and typography. A design system includes those rules plus coded, reusable components, interaction patterns and guidance on when to use each one.
When should a startup build a design system?
When it ships a second product surface, or when the same component starts being built twice. Start small — tokens and the ten most-used components — and grow it with feature work.
What are design tokens?
Named values for design decisions such as colour, spacing, type and radius. Instead of hard-coded hex codes, components reference tokens like color-action, so changing one token updates every place it is used.
How long does it take to build a design system?
A useful first version — foundations as tokens plus the core components — can be built alongside feature work over a few weeks. A mature system grows continuously as the product does.
