What a design system owes the people who use it

Design systems fail in a predictable way. They are built well, launched with a documentation site, adopted enthusiastically by the team that built them, and then quietly worked around by everyone else. Two years later there are four button components again, three of which are named after the system.

The post-mortem usually blames adoption, governance or executive sponsorship. Those are real, but they are downstream. The upstream problem is that the system was designed as a product for the organisation rather than as a dependency for engineering teams — and a dependency has obligations that a product does not.

A system is a dependency

When a team adopts your system, they are taking a dependency on your judgement, your release cadence and your responsiveness. They are accepting that some decisions are no longer theirs. In exchange, they expect the things you would expect from any dependency you took: that it is versioned honestly, that breaking changes are rare and announced, that the escape hatches work, and that when you cannot help them quickly, you say so.

Very few internal systems meet that standard. Versions are published without changelogs. Breaking changes arrive in minor releases. A team blocked on a missing variant is told to raise a request, and the request enters a backlog with no stated turnaround. All of this is survivable from a vendor you are paying. It is not survivable from an internal team you can bypass by copying the component into your own repository — which is exactly what happens.

Four obligations worth writing down

• Honest versioning. Semantic versioning applied properly, with a changelog that says what changed and what a consumer has to do about it.
• A stated response time for blocked teams. Not a promise to build everything, but a promise to answer within a known period, including with a no.
• Working escape hatches. A documented, supported way to extend or override a component, so a team that needs something unusual does not have to fork the system to get it.
• A contribution path that has actually been walked. If nobody outside the core team has successfully contributed, the path does not exist yet, whatever the documentation says.

Accessibility is the strongest argument you have

The most persuasive case for adoption is rarely consistency. Consistency is a benefit to the organisation, and the team deciding whether to adopt does not experience it directly. What they do experience is the cost of getting focus management, keyboard interaction and screen-reader announcement right in a combobox, and the risk of getting it wrong.

A system that has genuinely solved those problems — and can prove it with tests rather than with a statement of intent — offers a team something they want. That is a stronger foundation for adoption than a mandate, and it is a great deal more durable.

Teams adopt a system that removes work from them. They comply with a system that adds work, and compliance decays.

Design the deprecation before the launch

The question nobody asks at kick-off is how a component leaves the system. Components do become wrong: a pattern is superseded, an accessibility issue is discovered, a business rule changes. Without a deprecation process, the wrong component stays, because removing it would break consumers and nobody has agreed how much notice that requires.

Deciding this early costs an afternoon. Deciding it after three years of accumulation is a programme of work, and by then the system contains components everybody knows are wrong and nobody is permitted to remove.

The measure that matters

There are many metrics available for a design system, and most of them measure the system’s activity rather than its usefulness. The one we watch is the ratio of contributions from consuming teams to contributions from the core team. When it starts to shift towards the consumers, the system has become shared infrastructure. Until then it is a library one team maintains and other teams tolerate.