Designing a system nobody fights
A design system earns adoption the same way an API does — by making the right thing the easy thing.
- design systems
- process
Most design systems do not fail on craft. They fail on adoption.
The components are fine. The tokens are fine. The documentation is, at worst, serviceable. And yet six months in, half the product is built from one-off components that quietly forked from the library, and nobody can quite say when that started.
Adoption is an interface problem
A design system is a product whose users are engineers and designers, and like any product it gets adopted when the supported path is genuinely the cheapest one. If reaching for the library costs more than reaching around it — more lookup, more props to reason about, more escape hatches to negotiate — people will route around it, and they will be right to.
So the useful question is not is the component correct? It is:
- How long does it take to find the right component?
- How obvious is the right variant once it is found?
- What happens when a real design needs something the component cannot do?
That last one decides everything. A system with no escape hatch gets forked. A system that is all escape hatch stops being a system.
Make the seams explicit
The version I keep coming back to is a small, opinionated core with clearly marked seams — a handful of composition points that are documented as supported, not merely possible. Consumers get room to move without leaving the system, and the team gets a real signal: every time someone reaches for a seam, that is a feature request with usage data already attached.
The goal is not to prevent deviation. It is to make deviation visible.
Measure the thing you actually care about
Component count is a vanity metric. So is Figma library usage. The number worth tracking is the share of shipped UI built from system primitives — and, right behind it, how long a new pattern takes to go from one-off to supported component. When that second number is short, people stop forking, because waiting is cheaper than maintaining their own.
None of this is glamorous. It is mostly reducing the distance between what someone needs and what the system already offers, over and over. But that is the work, and it is the part that decides whether anyone uses what you built.