A design system is a promise, not a library

Most design systems I am asked to rescue have beautiful component libraries. Buttons in six sizes, every state documented, tokens named with care. And yet the product teams have stopped using them, and the same date picker exists in four slightly different versions.

The library wasn’t the problem. The promise behind it was never made.

What teams actually need to hear

A product team adopts a system when it believes three things. That the component will still be there next quarter. That if it breaks, someone will fix it quickly. And that if they need something new, there is a way to ask that doesn’t take a month.

None of these is a design problem. They are commitments about ownership, response time and roadmap, and they need a name next to them, not a Figma page.

Make the promise small and keep it

At Fernhill we started the system with nine components, not ninety. Each one had an owner, a changelog and a promise: bugs fixed within two working days, new requests answered within a week, even if the answer was not yet. We published those numbers where every team could see them.

For the first three months the system was smaller than what teams had built on their own. But it was reliable, and reliability spreads faster than coverage. By the end of the year the system shipped every new feature, and nobody had been asked to adopt it.

Measure trust, not coverage

Coverage reports look good in a slide, but they hide the important signal. I track two numbers instead: how many local copies of system components exist in product code, and how long requests wait for an answer. When copies go down and answers get faster, people trust the system. When either goes the other way, no amount of documentation will help.

If your design system feels ignored, look at the promises before the pixels. A smaller system that keeps its word beats a big one that doesn’t. More on how I set these up is on the about page.