TL;DR
- Start with design tokens (color, spacing, type) before building any component.
- Use variants inside one component, not multiple separately-named components.
- Written usage guidance matters as much as the components themselves.
A design system doesn’t need to be large to be useful — a small, well-organized one for a single project beats a sprawling, undocumented one every time. Here’s the order that actually works when you’re building one from scratch.
Start with tokens, not components
Colors, spacing, and type sizes as reusable values (design tokens) come first. If you jump straight to building buttons, you’ll end up rebuilding them once your color palette changes.
Build the smallest components first
Buttons, inputs, and tags before cards or page templates. Small components composed together are what make larger ones easy to update later.
Use variants, not duplicate components
A single Button component with variants (primary/secondary, small/large, disabled) is far easier to maintain than five separately-named button components.
Document usage, not just visuals
A design system without written guidance on when to use which component becomes inconsistent fast, even with perfect components. A short usage note per component saves far more time than it costs.
Version it like code
Treat breaking changes to core components as a version bump, and communicate them to whoever consumes the system — design systems that change silently erode trust and get abandoned.
The mistake most beginners make
Building the flashiest components first (cards, hero sections) before the boring foundational ones (buttons, inputs, spacing tokens) is the most common mistake. It feels productive, but you end up rebuilding those flashy components anyway once the foundation changes. See our Figma for beginners guide if you haven’t yet learned components and Auto Layout, both of which this relies on.
FAQ
What’s the first thing to build in a design system?
Design tokens — colors, spacing values, and type sizes — before any actual component. Components should reference tokens, not hardcoded values.
How big should a design system be for a small project?
Small and well-documented beats large and undocumented. A handful of core components with clear usage notes is more useful than dozens of undocumented ones.