"Design system" has come to mean something enormous — a dedicated team, a component library with a hundred entries, a documentation site with its own release notes.
For a small team that version is a trap. You'll spend three months building infrastructure for a product that needs four components, and abandon it.
What a small team actually needs is much smaller, and it's worth having from about your second project onwards.
What it's for
Not consistency for its own sake. A design system exists to stop you re-deciding things you've already decided.
Every time someone picks a grey by eye, chooses a border radius, or builds a card that's almost but not quite like the last one, that's a decision being made twice — badly, at speed, by whoever happened to be working that day.
A system is just the set of decisions you've agreed not to revisit.
Start with four things
In this order. Each is useful on its own, and each takes about an hour.
1. A colour palette with roles
Not "our brand colours". Colours named for what they're for:
- Brand: primary, and an accent if you need one
- Text: primary, secondary, muted, inverse
- Surface: page, raised, sunken
- Border: subtle, strong
- State: success, warning, error, info
Then check every text-on-background pair for contrast, and write down which combinations are allowed. This single step prevents most of the accessibility problems you'd otherwise fix later.
2. A type scale
Pick a ratio and generate sizes from it rather than choosing each one by eye. Define your headings, body, small and caption, each with a size, weight, line height and letter spacing.
Use rem units so it respects the reader's own settings.
3. A spacing scale
4, 8, 12, 16, 24, 32, 48, 64, 96. Use these and nothing else.
This is the highest-value, lowest-effort item on the list. It's what makes layouts look composed rather than assembled, and it removes an entire category of pointless decision.
4. Buttons
Every project needs them, everyone builds them slightly differently. Define primary, secondary and tertiary, at one or two sizes, with hover, focus, active and disabled states.
Four things. That's a working design system for a small team, and it'll carry you a long way.
What to add next, when you feel the need
Add these only when you've built the same thing twice and been annoyed about it:
- Form elements — inputs, selects, textareas, labels, error states
- Cards — one or two variants, not six
- Navigation — header, footer, mobile menu
- A grid — columns, gutters, page margins, breakpoints
- Icons — one set, one weight, one size scale
The trigger is repetition, not ambition. If you've built it once, it's not a component yet.
Where to keep it
Three places, and you want at least two of them agreeing.
In Figma, as variables and components. This is where design decisions get made, so it's where they should live.
In code, as CSS custom properties or — if you're in Webflow — as variables in the Designer, which work the same way. Define them once, use them on classes, change them in one place.
Written down, somewhere anyone can read. This is the part small teams skip and then regret when someone new joins. It doesn't need to be a documentation site; a page with your colours, your scale, your rules and a link to the files is enough.
A style guide page inside the site itself is a good trick. Unglamorous, takes an hour, and it's where you check things rather than hunting through the Designer.
The rules that keep it alive
One person decides. Systems die from committee. Someone owns it and has the final say on what goes in.
Adding is a deliberate act. A new component needs a reason, not just a project that happened to need something.
Name for purpose, not appearance. `brand-primary`, not `blue`. `space-large`, not `space-32`. Appearance changes; purpose doesn't.
Let it bend. A system that forbids everything gets ignored. Leave room for a one-off, and pay attention when one-offs start repeating — that's your next component telling you about itself.
When to stop
There's a point where more system stops helping. For most small teams it's around fifteen components.
Beyond that you're maintaining infrastructure rather than making things, and the maintenance cost is real: every component needs updating when the brand changes, testing when the framework does, and explaining to everyone who joins.
Build what you use twice. Ignore the rest.
Questions we get asked
How long does it take to set one up?
The four core pieces — colour, type, spacing, buttons — are about half a day for someone who knows the brand. Everything else grows out of real work rather than being built upfront.
Do I need a documentation site?
No. A page in your site showing every component, or a single well-organised Figma file, covers it for a small team. Dedicated documentation tools make sense when people outside your team need to build with your system.
What if our brand changes?
That's the argument for the whole thing. If your colours and spacing are named variables rather than values typed in forty places, a rebrand is an afternoon rather than a rebuild.
If you want a hand setting up the first version, or a review of one that's grown unwieldy, we're happy to take a look.