Building a Design System That Teams Actually Use

Start with the problems, not the components

The fastest way to build a design system nobody uses is to begin with a giant component library. I start with an audit instead: screenshots of every screen, grouped by pattern, with the inconsistencies circled. Within an afternoon the team can see that there are eleven shades of grey and six different buttons, and that makes the case for a system better than any slide deck.

Tokens first, components second

Color, type, spacing, radius, and elevation become tokens before a single component is drawn. Tokens are cheap to change, easy to document, and they give engineers something concrete to map to code. Once they are stable, components are mostly assembly.

• Name tokens by purpose (surface, border, text-muted), not by value.

• Keep the scale small. Four text sizes beat twelve.

• Support light and dark modes from the very beginning.

• Document what each token is for, and when not to use it.

Make it easy to adopt

A system only works if it is easier to use than to ignore. I ship a starter file, a short usage guide, and a changelog. I also hold a fortnightly office hour where anyone can bring a screen and we fit it to the system together. Adoption follows trust, and trust follows responsiveness.

Measure what matters

I track two numbers: how many screens use system components, and how long it takes to design a new flow. When the second number drops, everyone feels the benefit and the system defends itself.