Most design systems fail the same way. A team spends months producing an exhaustive component library and a forty-page brand document, and within a year the product contains six button variants that aren't in it. The system didn't fail because it was wrong. It failed because it was too big to keep current, so people stopped consulting it.
A design system's only real measure is whether people use it. Some teams still call this same artifact their brand identity guidelines; the name differs, but the discipline of keeping it small and current is identical. Everything below optimises for that.
Do you actually need one?
Probably not yet if: one or two people build everything, you have a single product surface, and you're still changing direction often. A shared colour palette and a font choice will serve you fine, and formalising too early locks in decisions you haven't earned.
Yes if: multiple people make visual decisions independently, you have more than one surface (web, app, email, decks, ads), or you've caught yourself asking "which blue is the right blue?"
The signal isn't company size. It's the number of people who can independently introduce an inconsistency.
Build in this order
Each layer depends on the ones above it. Building out of order is why systems become unusable.
1. Tokens
The atomic values — colours, spacing, type sizes, radii, shadows, motion durations. Everything else references these.
Keep the palette brutally small. A functional set is roughly: one background, two or three surface levels, one primary text, one secondary text, one or two accents, and semantic colours for success, warning, and error. That's it.
Every colour you add is a decision someone has to make correctly, forever. Teams that ship a fifty-swatch palette find eleven of them in use and forty in a document.
Same for spacing — a single scale (4, 8, 12, 16, 24, 32, 48, 64) covers nearly everything. Arbitrary values are the most common source of visual drift.
2. Typography
Three typefaces is the practical ceiling, and two is usually better. Give each one job — display, body, and optionally mono for labels and code.
Define a type scale with specific sizes, weights, and line heights, and name the roles rather than the sizes: heading-1, body, caption. Naming by role means you can change the size without renaming everything that uses it.
3. Primitives
Button, input, select, checkbox, link, card. Six or seven components covering the overwhelming majority of interface surface.
Constrain the variants hard. Three button variants — solid, outline, quiet — plus a disabled state and maybe two sizes. That's a dozen combinations, which is enough. A button component with nine variants and four sizes is a component nobody can use correctly.
4. Patterns
Compositions of primitives: a form layout, a page header, an empty state, a data table, a modal. This is where consistency actually shows up to users, and it's the layer most systems never reach because all the effort went into layer three.
5. Documentation
Last, and thin. For each thing: what it is, when to use it, when not to use it, and one example. The "when not to use it" line prevents more misuse than any amount of specification.
What keeps it alive
One source of truth, and be honest about which. If tokens live in Figma and are hand-copied into code, they will diverge — not maybe, will. Either generate code from design tokens automatically, or accept that code is authoritative and Figma follows. Pick one and say so out loud.
A defined way to add things. Someone will need a component that doesn't exist. Without a route to add it, they build it locally, and that's how you get six buttons. The route can be informal — ask in a channel, someone reviews it — but it has to exist.
Deletion as a routine activity. Systems accumulate. Review periodically and remove what nothing uses. A smaller system is a more used system.
Enforcement that isn't a person nagging. Lint rules that reject hardcoded hex values. A CI check on contrast ratios. Tokens exposed as CSS custom properties so the correct value is more convenient than the wrong one. Make the right thing the easy thing and adherence stops being a discipline problem.
The most common mistakes
Starting with components instead of tokens. Components built on hardcoded values have to be rebuilt when the palette changes.
Too many options. Every variant is a decision delegated to whoever uses it next, and decisions get made inconsistently.
Documenting appearance instead of intent. "Primary button is #075BC0" ages badly. "Primary button is for the single most important action on a page" doesn't.
No motion or dark-mode rules. Both get invented ad hoc by whoever ships first, and both are then very hard to unify retroactively.
Treating it as a project. A design system is maintained, not finished. Budget ongoing time or accept it will decay.
A realistic starting point
For a small team, a genuinely useful first version is roughly one page:
- A palette of eight to twelve colours with names and intended use
- Two typefaces with a five-step scale
- One spacing scale
- Button, input, and card, with their variants
- Rules for dark mode and focus states
That's a day or two of work, it fits in someone's head, and it will prevent most of the inconsistency you'd otherwise accumulate. Expand only when something specific forces it.
The system that exists and is used beats the comprehensive one that isn't.
Need a brand system built?
We build design systems sized to the team that has to maintain them, wired into code so they hold up. Talk to us about graphic design and branding.