Mention design systems and people picture dedicated teams, governance meetings, and documentation portals. So small teams conclude it's not for them — and keep redrawing the same button forty times a year.
The problem a system actually solves
Every time a designer improvises a spacing value or a developer eyeballs a hover state, the product drifts. Individually the drifts are invisible. Compounded over a year, the interface feels subtly broken and nobody can say why.
The minimum viable system
You need two things to start, and neither takes a month:
- Tokens — named values for your colors, type sizes, and spacing scale. When "brand navy" lives in one place, rebrands stop being archaeology.
- Ten components — audit your screens and you'll find the same pieces everywhere: button, input, card, modal, nav, table, badge, toast, tabs, footer. Build those once, properly.
What to deliberately skip
Skip the documentation site, the versioning policy, and the contribution guidelines. A shared file with real components beats a beautiful portal describing imaginary ones.
Growing it without ceremony
Add a component to the system the second time you need it, not the first. One-offs are fine; repeated one-offs are the signal. Review the system quarterly, prune what nobody uses, and promote what everybody copies. A design system for a small team isn't a project with an end date — it's just the habit of never solving the same problem twice.