How to get engineering to actually use the design system

When engineers don't use the design system, the instinct is to blame awareness or convenience: they don't know it exists, or it's too hard to import. Improve the documentation, add a codemods script, send a newsletter. These are not wrong responses, but they're not usually the real problem.

Engineers who have found and evaluated the design system and decided not to use it have a reason. It's usually one of three things: the system doesn't cover their case, it's hard to customize without fighting it, or using it produces output that doesn't match what the designer handed them. Any of those will produce an engineer who builds locally, even if the design system is beautifully documented and trivial to install.

The coverage problem

An engineer building a data-dense table view, a complex multi-step form, or a highly customized chart interface looks at the design system and finds that the components cover the marketing site and the settings page. There's no table component. The form inputs don't support the interaction pattern the designer specced. The buttons work fine but that's about half of what's needed.

At this point the engineer has a choice: use the design system for the parts it covers and build locally for the parts it doesn't, or just build everything locally so the codebase is consistent. Engineers often choose the second option, and it's not irrational. The design system's components won't look right alongside the custom components without significant styling work anyway.

The coverage problem doesn't get solved by better documentation or easier imports. It gets solved by finding out which product surfaces are being built outside the system and asking why. This requires talking to teams, not auditing Figma files. The people who know where the gaps are are the engineers who hit them.

The flexibility problem

The flexibility failure is more subtle. The design system has a button component. The engineer imports it. The design spec calls for the button to have a specific icon size, a slightly different label treatment, or a hover behavior that the button component doesn't support.

At this point the engineer either forks the component, wraps it and styles around it, or rebuilds it. All of these happen outside the system, but only the rebuild shows up as non-adoption. The fork and the wrapper look like adoption because the system component is technically in the codebase.

Components that don't expose enough of their surface area through props produce hidden non-adoption. Engineers use the component as a starting point and then stop using the system's implementation as soon as they need to diverge. The button in their codebase imports from the design system package but looks and behaves completely differently than the system intends.

The signal to look for: component overrides. If engineers are importing components and immediately wrapping them in a layer of CSS overrides or adding wrapper divs to change the layout, the component's API isn't reaching what they need to change. This is fixable: add the prop, expose the slot, make the behavior configurable. But you have to see the pattern first.

The spec mismatch problem

The most adoption-killing dynamic is when engineers follow the design system and produce output that designers reject in review.

This happens when the Figma design references components with different behavior than what's implemented. A designer uses a tooltip component with a 200ms delay. The code component has a 300ms delay and no prop to change it. The engineer ships the code component. Design review flags it as wrong. The engineer is now in a situation where using the design system means failing design review.

Once this happens a few times, the engineer's mental model of the design system shifts: it's a reference library, not a source of truth. They'll look at it, but they'll build what the designer actually asked for, which means building custom.

This dynamic is a design systems team failure, not an engineering failure. The Figma component and the code component are saying different things, and the engineer is caught between them. The fix is obvious. Synchronize them. But identifying that this is the root cause of adoption problems requires actually asking engineers what they find frustrating about using the system.

What works

Adoption grows when engineers trust that using the system will produce the correct output, when the system covers their actual use cases, and when it bends without breaking when they need to do something slightly unusual.

The practical moves: identify two or three engineering teams that are heavy system non-users, have a conversation about why, and fix the specific problems they name. Not a survey. A conversation. Engineers are usually direct about what doesn't work if you ask sincerely. One team's feedback about a missing component or a props gap is usually shared by several others who didn't bother to say anything.

Early system advocates inside engineering teams matter as much as any documentation improvement. An engineer on a product team who genuinely likes using the system and talks about it is more persuasive than any amount of outreach from the design systems team. Finding and supporting those people, making sure their feedback gets acted on quickly and giving them early access to new components, pays back more than most adoption initiatives.

The one pattern that doesn't work: requiring adoption. Mandating that engineering teams use the design system without fixing the reasons they're not using it produces adoption metrics that look healthy and a product that looks inconsistent, because engineers will import the system components and immediately work around them.