A design system is the shared language of your product: the colours, type, spacing, components and rules that every designer and developer uses. Big companies have dedicated teams for theirs, but you don't need one to get the benefits. A small, well-chosen system can make new pages faster to build, more consistent and more accessible within weeks. Here's how to build one with a small team.
What's in a design system
| Layer | What it includes | Example |
|---|---|---|
| Design tokens | Named values for colour, type, spacing, radius, shadows | color-primary, space-4, radius-lg |
| Components | Reusable interface pieces with variants and states | Button, input, card, modal, navigation |
| Patterns | Combinations of components for common tasks | Sign-up form, pricing table, empty state |
| Guidelines | When and how to use each part | "Use one primary button per view" |
| Code | Components implemented in your front end | A React component library, Storybook |
Design system vs style guide: a style guide documents visual rules; a design system adds reusable components and code that make those rules easy to follow. Our article on building a brand style guide covers the brand side.
Step 1: Audit what exists
Collect screenshots of every button, input, card, colour and text style currently in use. Most teams discover a dozen shades of grey and several slightly different buttons. This audit shows where to start and makes the case for the system.
Step 2: Define your tokens
Tokens are the foundation. Start with:
- Colour: brand colours, neutrals, and semantic roles such as success, warning, error and focus
- Typography: font families, a type scale, weights and line heights
- Spacing: a consistent scale, often based on 4px or 8px steps
- Radius and elevation: corner radius and shadow levels
| Token type | Small-team starting point |
|---|---|
| Colours | 2–3 brand colours, 6–9 neutrals, 4 semantic colours |
| Type sizes | 6–8 steps, from caption to display |
| Spacing | 8–10 steps |
| Radii | 3–4 values |
Name tokens by purpose, not appearance: color-text-muted lasts longer than grey-500 when the palette changes. Check every text and background pairing against WCAG contrast, using our WCAG 2.2 checklist.
Step 3: Build the core components first
Don't try to systemise everything. Start with the components used most:
- Buttons (primary, secondary, tertiary, destructive; all states)
- Form inputs, selects, checkboxes and radios
- Cards
- Navigation and links
- Modals and alerts
- Typography components (headings, body, captions)
For each, design every state: default, hover, focus, active, disabled, loading and error.
Step 4: Match design and code
A system only works if Figma and the live product agree.
- Use the same token names in Figma variables and in code
- Build components in code with the same variants and props
- Use a tool like Storybook so developers can see and test components
- Agree a single source of truth for each token
Step 5: Document just enough
Documentation should answer practical questions quickly:
- What is this component for?
- When should I use it, and when shouldn't I?
- Which variants exist?
- What are the accessibility requirements?
A short page per component, with do and don't examples, beats a 100-page manual.
Step 6: Govern it lightly
| Question | Simple answer for small teams |
|---|---|
| Who can change components? | One design owner and one engineering owner |
| How are changes proposed? | A short request with the use case |
| How are changes released? | Versioned updates with a changelog |
| How do we avoid drift? | Regular design reviews of new screens |
Common mistakes
- Building a huge library before anyone needs it
- Designing components that don't exist in code
- Naming tokens after colours instead of roles
- Ignoring accessibility until the end
- No owner, so the system slowly falls out of date
Signs it's working
- New pages are designed and built noticeably faster
- Fewer one-off styles appear in reviews
- Accessibility issues drop
- Designers and developers argue less about details
Tools for a small-team design system
| Need | Common tools |
|---|---|
| Design components and tokens | Figma with components and variables |
| Code components | React, Vue or your front-end framework |
| Component documentation and testing | Storybook |
| Token syncing between design and code | Token export plugins or a shared token file |
| Accessibility checks | Contrast checkers, automated testing tools, manual keyboard testing |
| Versioning and releases | Git with a changelog |
You don't need every tool on day one. Figma plus a well-organised component folder in code is a solid start.
A six-week plan
| Week | Focus |
|---|---|
| 1 | Audit existing screens and agree priorities |
| 2 | Define colour, type, spacing and radius tokens |
| 3 | Build buttons, inputs and form controls in design and code |
| 4 | Build cards, navigation, modals and alerts |
| 5 | Document components and accessibility rules |
| 6 | Apply the system to a real page, gather feedback and refine |
By the end, you'll have a working core that real pages use, which is far more valuable than a large library that nobody has adopted.
How we help
We build design systems in Figma matched to your code, starting with an audit and the components your product uses most, then documenting and handing them over so your team can extend them.
The short version
Audit what exists, define purpose-named tokens, build the most-used components with every state, keep Figma and code in sync, document just enough and give the system an owner. Start small and grow it as your product grows.
