Empathy leads to adoption
Design systems don't fail because the components are bad. They fail because the people building them forget who they're building for.
The adoption problem is a people problem
Every design systems team I've talked to has the same story. They spend months building a beautiful, well-documented, accessible component library. They write the migration guides. They set up the Slack channel. And then... adoption stalls.
The components sit unused. Teams keep their own libraries. The system becomes a side project that a few advocates maintain while everyone else ships without it.
This isn't a quality problem. Most of the time, the components are good. It's an empathy problem.
What engineers actually need
When I joined my last team, I spent the first month doing something unusual: I sat with engineers during their sprints. Not to pitch the design system, just to watch them work.
What I saw changed how I thought about our job. Engineers weren't ignoring our components because they were bad. They were ignoring them because:
- The documentation assumed too much context
- The prop APIs were designed for the designer, not the developer
- Migration felt risky with no clear upside for their immediate sprint
Every one of those is fixable. None of them are fixed by making the components better.
Embedding beats announcing
The highest-leverage thing a design systems team can do is embed with product teams during real work. Not in a supervisory role — as a partner.
When you're in the room when a team is trying to solve a hard layout problem, you can show them the system tool that solves it in real time. That single moment is worth more than ten pages of documentation.
The shift in mindset
The teams that succeed at building adopted design systems share one thing: they think of adoption as their core metric, not component coverage.
It doesn't matter if you have 200 components if teams aren't using them. It matters that the 20 components teams reach for most often are so good, so well-documented, and so easy to integrate that using the system is the path of least resistance.
Build for the developer who is tired, under deadline, and just wants the thing to work. That person is your user. Design for them.