Getting developers to actually use the design system

Why it is hard at first

Developers are not difficult people. They are busy people who have been burned before. Most of them have received beautiful designs that ignored how the product really works, components that existed only in Figma and rules that changed every other week. So when a designer arrives with a new system, the natural reaction is suspicion: is this one more layer of work, one more thing that will slow us down?

That suspicion is fair, and arguing with it doesn’t help. What helps is showing, as quickly as possible, that the system takes work away rather than adding it.

Authority, used carefully

Someone has to own the system, and on my teams that someone is me. That means having the final word on visual and interaction decisions: which components exist, how they behave and when an exception is acceptable. Without that authority, a system slowly dissolves into a collection of local variations, each perfectly reasonable on its own.

But authority only works if people trust it. I earn that by being consistent, by explaining the reasons behind the rules and by changing my mind openly when a developer shows me something I missed. The rule I hold myself to is simple: I can insist on a decision only if I can explain it. If I can’t, it isn’t a rule yet.

Creativity in the approach

Authority sets the boundaries; creativity gets people across them. Over the years I have stopped presenting systems and started meeting developers where they already are. I speak in their terms: tokens are variables, components have properties and states, and the registry reads like documentation rather than a mood board. I make sure the system exists in code, not just in design files, so using it is the path of least resistance.

I also look for the first small win. A developer who builds a complex form in an afternoon because the fields, validation states and spacing are already there becomes the system’s best advocate, far more convincing than anything I could say. And I keep a learning space next to the library, with short notes on why things are the way they are, so nobody has to ask me the same question twice.

Once they start

The change, when it comes, is striking. The same developers who doubted the system start defending it. They point out inconsistencies before I do, propose new components with proper states and naming, and push back on anyone who tries to hard-code a colour. The conversations between design and development become shorter and calmer, because both sides are speaking the same language.

That respect is worth every difficult conversation at the start. A design system that developers truly use is not something a designer can impose. It is something the whole team chooses, once they have seen for themselves how much easier it makes the work. My job is to lead them to that point with enough firmness to hold the line and enough imagination to make the line worth holding.