A design system isn't a Figma file. It's a contract between designers and engineers that says: "we agreed on this once, so we don't have to argue about it again."
The teams that get value from design systems are usually the ones that approach them as code-first products with internal customers — not as documentation projects. This post is about what to build, when, and what almost always goes wrong.
When a design system is actually worth building
Don't build one too early. The signs you should build one:
1. The same component lives in three places
When new hires are quietly recreating the same Button or Input because they can't find the existing one, you have a discoverability problem masquerading as a quality problem.
Key takeaway: Component duplication is the loudest signal you've earned the right to a design system.
2. Pixel drift between similar screens
If two screens that should be siblings feel subtly different, your team is making the same micro-decisions repeatedly. A design system stops that.
Key takeaway: Visual consistency at the screen level usually means consistency at the token level.
3. People asking "which one should I use?"
A design system replaces tribal knowledge with a single answer. If your Slack is full of "is there a standard for this?" questions, you have your roadmap.
Key takeaway: Friction questions reveal where your system's surface area should be.
The three layers worth getting right
Most design systems collapse if you skip a layer.
1. Tokens
Color, spacing, typography, radii. These should live in code, not Figma. Figma is the design surface; the source of truth is shipped CSS variables or Tailwind theme entries.
Key takeaway: If your tokens live only in Figma, you don't have a design system. You have a moodboard.
2. Primitives
Buttons, Inputs, Dialogs, Selects. These should be headless behavior + styled wrapper, so you can swap the styling without rewriting the logic.
Key takeaway: Use a battle-tested headless library (Radix, Base UI) and own the styling. Don't write your own focus management from scratch.
3. Patterns
Forms, tables, empty states, dashboards. Patterns are compositions of primitives, and they're where most of the actual product work happens.
Key takeaway: Patterns are where your design system stops being generic and starts being yours.
"Standards are like toothbrushes. Everyone agrees you need one. Nobody wants to use someone else's."
Tools that actually help
You don't need a custom build system. Most teams ship great design systems with off-the-shelf tools.
1. shadcn/ui for primitives
Copy-paste, headless, owned-by-you primitives. You modify them like normal code, no library lock-in.
Key takeaway: Start with shadcn/ui and customize as you need; don't reinvent it.
2. Tailwind CSS for tokens
Tailwind's theme config gives you a tokens layer for free, plus utility classes that make pattern work fast.
Key takeaway: Token discipline matters more than design system tooling.
3. Storybook only when you need it
Storybook is great when you need component-level documentation across multiple consumers. For small teams, it's overhead.
Key takeaway: Add Storybook when documentation is the bottleneck — not before.
What almost always goes wrong
A few patterns that have killed otherwise good design systems.
1. Treating it as a side project
A design system maintained on Fridays will die. The teams that succeed treat it like any other product, with a roadmap and customer feedback.
Key takeaway: No clear owner means no design system in 12 months.
2. Too much abstraction, too early
Resist the urge to make every prop configurable. Start opinionated, then loosen.
Key takeaway: A boring, predictable design system beats a clever flexible one every time.
3. Ignoring engineering ergonomics
If using the system feels worse than writing custom CSS, engineers will quietly route around it.
Key takeaway: Design systems are products with engineers as users. Their DX matters.
Closing thought
The best design system is the one your team actually uses. Bias toward small, boring, predictable, and well-documented. The flashy stuff is a trap. Ship the basics, watch how people use them, and let the patterns emerge.
