We’ve built or contributed to design systems for a dozen companies. The pattern is always the same: a talented design team creates a beautiful, comprehensive system in Figma. Then engineers ignore it and keep building components from scratch. Six months later, the design system is a graveyard of outdated tokens and unused components.
The problem is almost never the design quality. It’s the developer experience. If using the design system is harder than not using it, engineers will route around it every time. They’re not being difficult — they’re being rational.
Here’s what we’ve found works. First, ship components, not guidelines. A page in Notion explaining your spacing scale is not a design system. A npm package with a <Stack gap={4}> component is. Engineers adopt tools, not documents.
Second, optimize for the common case. Your Button component should work perfectly with zero props. Every required prop is friction. Every prop that requires reading documentation is a reason to just write a <button> with inline styles instead.
Third, build in public within your org. Every design system change should be visible — a changelog, a Slack notification, a migration guide. Engineers hate surprises. If a component API changes and they find out when their build breaks, you’ve lost trust that takes months to rebuild.
The best design systems we’ve seen treat engineers as their primary users, not an afterthought. Design the API before you design the visuals. Write the code example before you draw the Figma frame.