A design system is a product, not a library

Every team I’ve worked with has a folder called components. Most of them also have a Figma file called “Design System v3 (final)”. Very few of them have a design system.

The difference isn’t the number of buttons or how complete the documentation is. It’s whether anyone treats the thing as a product.

Who are your users?

A design system has two groups of users, and both of them are busy:

• Designers, who want to move fast without redrawing the same card for the fortieth time.
• Engineers, who want components that behave predictably and don’t break when the next version ships.

If you can’t name a few people in each group and say what slows them down this month, you’re building a library. Libraries get finished. Products get used.

A component nobody asked for is a liability with good documentation.

Keep a roadmap, and keep it short

At Fieldnotes we kept a public list of the next five things the system would support. Not fifty. Five. Teams could see what was coming, suggest swaps, and plan around it. Everything else went into a parking lot that we reviewed once a month.

That one page did more for adoption than any amount of polish. People trust a system when they can see where it is going.

Someone has to say no

The hardest part of the job is turning down requests. A one-off variant for a single screen feels harmless, but each one makes the system a little harder to learn and a little slower to change.

A simple rule helped us: a pattern joins the system when three teams need it. Until then, it lives in the product that needs it, and we watch.

Measure what matters

We tracked three numbers each quarter:

1. How much of the product UI used system components.
2. How long it took to ship a new screen from design to production.
3. How many bugs were caused by the components themselves.

The first went up, the second went down, and the third stayed boring. That’s what success looks like for a design system: quiet, dependable and everywhere.