Design systems get a bad reputation because most of them are built at the wrong moment. Too early, and you are governing components nobody is using. Too late, and you are paying down the visual debt of a hundred one-off Figma files.
The right time is when shipping starts to slow down for reasons that are entirely your own making. Same button, four implementations. Same form, three field libraries. Same colour, six hex codes.
Build for the team you have, plus one
A design system should fit the team a quarter from now, not the team in three years. Anything more is speculative architecture, and you'll pay for it in maintenance.
Start with the surfaces you ship most often. If marketing pages move weekly and the product moves monthly, your system should make marketing fast first.
Tokens before components
Components are the easy bit. Tokens — colour, spacing, radius, typography, motion — are where the system either compounds or collapses.
Get the token layer right and every future component inherits it. Skip it and you'll be retrofitting variables into a codebase that has already metastasised.
Semantic, not decorative
Name tokens by intent, not by appearance. `surface-elevated` ages well; `gray-200` does not. The day you redesign the palette, semantic tokens cost minutes to swap and decorative ones cost weeks.
The same principle applies to components: `Empty State`, not `Centered Card With Icon`.
Govern lightly, document obsessively
The most common design system failure mode is heavy governance with thin documentation. Designers ask permission to add a variant, then ship it as a one-off because the docs don't explain when to use what.
Invert it. Document the why for every primitive. Let teams compose freely. Audit quarterly.
Measure the right thing
The point of a design system is leverage. Measure time-to-first-pixel on a new surface, frequency of one-off components, and consistency of patterns across teams.
If those numbers aren't moving, the system isn't earning its keep, no matter how beautiful the Storybook is.
Treat the design system as a product whose customer is your own team. Ship it in versions, measure adoption, and only build what is being used. The system that survives is the one that pays back faster than it costs.