Every few months, someone publishes a design system that looks immaculate in a portfolio deck. Perfectly named tokens. Pristine component audits. A color palette that reads like a poem. And every time, I have the same reaction: this isn’t the hard part.
The hard part is what happens six weeks later, when the first edge case lands — a form state that was never mocked, a data density that breaks the card grid, a dark-mode variant that reveals an entire branch of unconsidered surfaces. The system either bends or breaks.
The living system
A design system that survives contact with real products is not a deliverable. It is a practice. It lives in pull requests, not in a Figma library. It changes shape as the product changes shape. The team that maintains it is the same team that builds with it.
This is why I’ve come to believe that the health of a design system correlates directly with the proximity between its maintainers and its consumers. When the person writing the component is the same person using it in a feature, the feedback loop is measured in minutes. When they sit in different organisations, it is measured in quarters.
What good looks like
Good design systems share a few observable traits:
-
They are boring. The best systems don’t excite designers — they make implementation predictable. Every component has one obvious way to use it.
-
They are incomplete by design. Coverage is not the goal. A system that tries to model every possible variation becomes a cage. The best systems define the common path and trust teams to extend when needed.
-
They are the product. The system is not a support function. It is the surface area through which every user experiences the product. Treating it otherwise guarantees drift.
-
They have a single source of truth in code. Not in Figma. Not in Confluence. In the repository where the components actually live.
A modest proposal
If you are starting a design system today, resist the urge to begin with a visual audit. Start instead with the component that causes the most inconsistency across your product — probably a button, a form field, or a modal. Design it once, implement it once, and use it everywhere. Then do the next one.
After ten components, you’ll have something more valuable than a complete audit: a practice.
Comments