A design system is a contract, not a library
Writing team:
Ruth Alvarez Principal designer
Tomas Nyberg Engineering leadComponents are the easy half. The agreement about who may change what is the part that fails.
Components are the easy half
Most design systems ship a component library and call it done. The library is real work, but it is the part with the clearest brief: here are the buttons, here are the states, here is the spacing scale.
What fails later is never the button. It is the disagreement about who is allowed to change the button, and what happens to everyone else when they do.
The agreement is the artefact
A system that works is a written agreement between the people who maintain it and the teams who consume it. It says what is guaranteed, what is negotiable, and what breaks a release.
- Guaranteed: the visual language, the accessibility floor, the public props.
- Negotiable: composition, layout, anything a team can build without forking.
- Breaking: renaming a prop, changing a default, removing a variant.
Versioning is a design decision
The moment two products consume the same component, the system has an API, and an API needs a version policy. Deciding that late is how a system ends up with four copies of the same card.
Signs the contract is missing
Teams keep a local override file. Nobody can say who owns a token. A change lands and someone finds out in production. All three are the same problem wearing different clothes.
Ship the next release with a team that has done this before
We join in-flight products and leave them faster to change than we found them. Research, design and front-end, on one clock.
View services
