Design systems are 25% pixels, 75% people

The tokens, the components, the Figma library, the published package: that's the 25%, and it's the easy 25%. A design system can be technically excellent and still sit mostly unused, because the thing that decides whether people reach for it has almost nothing to do with how well it's built. The other 75% is the work of getting humans to change what they do by default, and that work is design and code only at the margins. It's persuasion and trust, built one team at a time.

This isn't an argument that the artifacts don't matter. A system that's badly built won't survive contact with the first hard use case, and craft is the price of entry. But craft is the price of entry, not the thing that wins, and teams that have done the building well are often the most surprised when adoption stays flat anyway.

Why the easy part gets all the attention

The reason teams pour their effort into the 25% is that it's the part you can watch finishing. A component ships and the changelog grows. Both are legible to the team building it and to whoever is asking how the system is going, and that legibility is its own reward. You can point at a library of sixty components and feel like the work is happening.

The people work offers none of that. Convincing a skeptical engineering lead to try the system again after a bad first experience produces no artifact. It doesn't show up in a changelog. It's slow and uncomfortable, and it asks the design-system team to spend its days persuading other people instead of building, which is often the opposite of why those people got into the work. So the hours drift toward the components, the adoption stays flat, and everyone wonders why a system this good isn't catching on.

The 75%, named

Most of the 75% is familiar once you lay it out. Making the system the path of least resistance, so that reaching for it is genuinely easier than rolling something custom. Earning enough trust that an engineer who uses a system component doesn't get flagged in design review for it. Making the cost of going custom visible to the people choosing to go custom. Finding the engineers and designers who already like the system and giving them reasons to talk about it.

I've written elsewhere about the mechanics of each of these, especially the post-launch question of why engineers who have evaluated the system still go and build their own. What I want to sit with here is the part that comes earlier and gets filed as a technical decision when it's really a human one.

The hardest part comes before anyone adopts anything

Two product teams each have a button. They're ninety percent the same and differ in ways that matter to no one but the people who built them. Merging them into a single system button is a five-minute technical exercise and a three-week social one, because each team believes their version is the right one and neither wants to be the team that gave theirs up. The hard part was never deciding which properties the button should expose. It was getting two groups of people who weren't asking for your help to agree to share something, and to keep agreeing as edge cases surface months later.

Deprecation is the same shape, sharper. A team has a local component that works for them today. You're asking them to tear it out and adopt the system's version, which will cost them a sprint and give them very little they can feel, in exchange for a consistency the whole org benefits from somewhere down the line. From the org's vantage point it's obvious. From inside that team's roadmap it's a tax you're imposing for someone else's benefit, and reading their reluctance as obstruction rather than a sane response to their own incentives is how you lose them for the next ask too.

Governance is where this never ends. A contribution model and the principles behind it get written down once and then renegotiated every time a real case tests them. The document only records where the negotiation last landed. The real governance is the standing conversation about whose needs the system serves when they conflict, and that conversation doesn't close. None of this is adoption in the usual sense. Nobody has shipped anything to a user yet. It's all change management, happening while the system is still being built, and it decides whether there's anything worth adopting later.

What changes if the split is real

If you take the split seriously, a few things about how you run a design-system team stop making sense in their usual form.

It starts with who you hire. A team staffed entirely with people who are excellent at building components is staffed for the 25%. At least one person on it should be there for their ability to build relationships and earn trust across teams, and that ability should be valued in the same breath as technical craft instead of treated as a soft extra the manager handles on the side.

It shows up next in how you budget time. If adoption work is what happens in the gaps between building components, it will always lose to building components, because the components have due dates and the relationships don't. The negotiation, and the office hours that go out to teams instead of waiting for them to show up: this is the work, and it belongs on the roadmap with time attached.

And it changes what you count as success. Library size measures the 25%, and a team optimizing for component count is optimizing for the easy part and calling it progress. The measures that track the 75% are harder and softer: how often new code reaches for the system by default, and whether teams trust it enough to use it without double-checking. They resist clean dashboards, which is most of why they get skipped.

You can't announce it into being

The day you know the 75% landed is an ordinary one. You notice an engineer reaching for the system component without being asked, because it genuinely was the easiest path in front of them. Or one of them talks a teammate out of forking it, because they'd rather improve the shared one than start over. Nobody filed a ticket and nobody ran a campaign. The system had quietly become the thing people reach for when they aren't thinking about it, which is the only kind of adoption that was ever going to hold.