Every growing company eventually has a moment where someone (usually a new designer or a frustrated engineer) asks "wait, which blue do we use?" The honest answer is almost always "we have nine." That is the moment a design system goes from optional to overdue.
What a design system actually is
A design system is not a library of components. It is a shared agreement about how decisions get made. The components are the visible part. The invisible part (naming, tokens, spacing scale, motion rules, accessibility defaults) is what makes future decisions cheap. Without that agreement, every new screen is a fresh debate.
The cost of not having one
The cost shows up as drift. Three button styles instead of one. Two date pickers because nobody knew the first one existed. A new hire who spends their first month asking what the official font weight is. None of these are catastrophic on their own, but compounded over a year of shipping, they translate into measurable engineering hours, slower onboarding, and a product that visibly does not trust itself.
You do not need Material Design
The biggest mistake we see in early-stage teams is over-scoping the system. Google has a design system because Google has 200 product surfaces. You have eight. Your v1 should fit on a single Figma page and a single TypeScript file. If it cannot, you have built documentation, not a system.
What goes into the first version
- A spacing scale: usually a 4 or 8 px ramp. Pick one and ban the rest.
- A type ramp: five sizes is plenty. Display, heading, body, small, caption.
- Colour tokens: semantic names like surface, ink, accent, never raw hex codes in components.
- Six to ten components: button, input, card, badge, link, modal. The rest can wait.
- A motion primitive: one easing curve, three durations. That is most products covered.
- One page of writing principles: voice, casing, error tone. The most undersold part of any system.
Make it a product, not a PDF
Design systems that live in a PDF or a Notion page die the moment the next sprint starts. The systems that survive are the ones that ship as code. Tokens as variables, components as imports, documentation co-located with the source. The bar is simple: a new engineer should be able to build a passable screen on day one without asking a designer a single question.
“Treat the design system the way you treat a customer-facing product. It has users, a roadmap, and bugs. Staff it accordingly.”
How to know it is working
A working design system has three signals. New screens look like the old ones without anybody trying. Code reviews stop arguing about spacing and start arguing about logic. And the longest sentence in any design brief becomes "use the standard pattern." When you hit those three, you can stop polishing the system and go back to shipping the product. Which was always the point.
