A Design System Is a Product, Not a Style Guide
The design systems that get adopted have a roadmap, a changelog, and someone who says no to bad additions. The ones that don't are just a Figma file nobody opens anymore.
Every design system we've inherited from a client started the same way: a well-intentioned Figma library and a matching component package, built in a sprint, documented once, and never touched again except to add one-off variants nobody reviewed. Within a year, half the app used the system and half had quietly forked around it.
The tell that a design system has failed
The clearest signal isn't low adoption — it's inconsistent adoption. Some teams use the system faithfully. Others have a parallel set of "temporary" components that became permanent, because getting a real change into the shared system took longer than just building around it.
If working around your design system is consistently faster than contributing to it, that's not a discipline problem on the team bypassing it. That's the system telling you its process is too slow.
Treating it like a product, concretely
The shift that actually fixed adoption was organizational, not technical: we started running the design system with the same rigor as any other product — an owner, a public roadmap, a changelog, and a real intake process for new component requests.
## Changelog — v4.2.0
### Added
- `<DataTable sortable />` — requested by Billing, generalized for platform use
### Changed
- `<Button>` loading state now uses the shared spinner primitive (breaking: removed `isLoading` prop, use `loading`)
### Deprecated
- `<LegacyModal>` — migrate to `<Dialog>` by v5.0.0
Someone has to be allowed to say no
The other change was giving the system owner real authority to reject additions that don't generalize — a one-off component built for a single team's edge case doesn't belong in the shared system just because that team asked first. Every rejected request gets a documented reason and, where possible, a path to get the general case added properly later.
"A design system that accepts everything isn't a system anymore. It's just a components folder with extra steps."
Component contribution requests before and after the intake process
What adoption looks like now
With an intake process, a visible roadmap, and someone accountable for saying no, contribution requests from product teams roughly doubled — not because we made it easier to add anything, but because teams could see a real path for their genuine needs to land, instead of forking around a system that felt closed to them.
One email, every other Friday
Engineering notes, new articles, and things we learned the hard way — no marketing, ever.
Read by 2,400+ engineers. Unsubscribe anytime.
Let's talk
Let's build what's next.
If any of this sounds like the kind of work you want done on your systems, our engineers are the ones who'll actually do it.