The Design System Nobody Follows
The design system nobody follows isn’t the one that was built wrong. It’s the one nobody knows exists.
This is what most teams get wrong: they build a beautiful system, document it thoroughly, and then wonder why engineers keep writing custom styles and designers keep reinventing components. The conclusion is almost always the same — we need to improve the system. Better documentation. More components. Cleaner tokens.
Wrong diagnosis. Wrong treatment.
The system didn’t fail because it was bad. It failed because adoption is a distribution problem, and the team treated it like a quality problem.
The quality trap
When a design system has low adoption, the instinct is to make it better. Add more components. Write better docs. Hold a workshop. Record a Loom.
None of that is wrong, exactly. But it’s optimizing the product when the problem is in the channel.
Think about any product with a distribution problem. Making it 10% better doesn’t move the needle. Getting it in front of the right person, at the right moment, in the right format — that’s what changes behavior.
Design systems work the same way. The barrier to adoption isn’t “this doesn’t have the component I need.” It’s “I forgot it existed” or “I didn’t know it had that” or “by the time I found the answer, I’d already written the CSS.”
That last one is the one nobody admits. The system lost not because it was wrong — but because it was slow to find.
What distribution actually looks like
The best-adopted design systems I’ve seen share one thing: they’re impossible to avoid.
Not because anyone forced the team to use them. Because the system lived in the places where work was already happening. A snippet in the IDE. A plugin in Figma that’s already open. A doc pinned to the team’s Notion page. A Slack channel where someone answers questions within an hour.
That’s distribution. The system showing up in the workflow rather than sitting in a wiki nobody navigates to.
Three patterns that actually move adoption:
- Inline discovery over centralized docs. A component library in Figma that surfaces as you search beats a Notion doc you have to remember to open.
- Change communication that reaches people. A changelog Slack post beats a versioning section buried in the docs. Send it where the work happens.
- A fast answer path. The fastest route to adoption is “does the system have X?” getting answered in under two minutes. If it takes twenty, people build their own.
The uncomfortable implication
If adoption is a distribution problem, then the team maintaining the system isn’t just a craft team — they’re a growth team. They have an audience (the designers and engineers who build with it), a product (the system), and a distribution challenge (getting people to use it instead of rolling their own).
Most design systems teams don’t think this way, because they were hired to build, not to distribute.
That’s the gap.
The design system nobody follows probably isn’t bad. It’s sitting in a place where nobody is when they need it.
Fix the distribution first. Then see what’s actually wrong with the product.