Design System Adoption Across Multiple Applications

Context

I’ve worked on design systems across several companies. The problems repeat.

Someone builds a component library - usually under pressure, usually while the product is also moving. The components are solid. The documentation is reasonable. And then teams keep writing custom UI anyway, because using the system wasn’t worth the friction. The system exists. Nobody adopts it. Eventually someone proposes a rewrite.

The work I want to talk about is what happens between shipping components and teams actually reaching for them.

Challenge

The technical challenge of a design system is well-understood: consistent APIs, good defaults, flexible overrides where they matter. That part is satisfying in a way software rarely is - you design an interface once and the decisions compound across every consumer.

The organizational challenge is less documented. Teams under deadline pressure build around components rather than contributing fixes. Designers specify interactions that don’t map to existing component behavior, and engineers either hack the component or ignore the system entirely. You end up with drift - not because anyone made a bad decision, but because the system didn’t make the right path easy enough.

When a team is working around one of your components, you can blame them or treat it as a signal. I tried to do the latter.

Approach

Getting teams to treat the design system as something they depend on rather than something they work around - that’s the actual problem.

The approach that worked: working groups. Regular, open forums where any team could bring requests, questions, or friction. Not a ticket queue, not a changelog - a conversation. I stayed accessible outside of that too. If someone needed a call to understand a decision or wanted to push back on a direction, I was there. When engineers have input into the thing they’re asked to use, the adoption problem mostly takes care of itself.

API discipline was the other side of it. Every component that goes into a design system has to be maintained indefinitely. You can add things - you almost never remove them, because teams start depending on edge cases before you notice. When requests came in for specialized behavior that only one team needed, the honest answer was usually: that’s a custom product problem, not a design system problem. Solving it in the shared system means everyone pays the maintenance cost forever.

I didn’t always get that call right. But asking the question before building became habit.

At some point the system moved from my sole ownership to team-contributed. Right call - a single maintainer is a bottleneck, and a good system should outlast any one person’s attention. Letting go was harder than I expected, not because I didn’t trust the people, but because I’d come to think of the system as a quality multiplier: whatever standard it sets tends to spread through everything built on top of it.

What I landed on was oversight without control. Reviewing API designs before they merged. Coaching contributors through the reasoning behind decisions - not just the decision itself, so the pattern could carry forward. Staying in sync with design so engineering changes didn’t happen in isolation. Teams could contribute. The standards held.

Outcome

Over 30 components in active use across multiple products. The contribution model shifted: other engineers were adding components and I was reviewing for architectural fit rather than building everything myself. That transition is the metric I’m most satisfied with - it meant the system had enough momentum to survive without a single owner.

Reflection

Building the system is maybe a third of the job. The rest is everything that makes teams actually reach for it.

I got better at listening - actually listening, not waiting to redirect toward what we’d already built. I learned to slow down when requests felt urgent and ask whether we already had something that covered it. The best decisions I made repeatedly on this kind of work weren’t technical. They were telling product: we already have something for this. Let’s use it.