Design systems at scale

Building components is the easy part. Running a design system for many teams over years is an ongoing product and organisational challenge.

Team models

• Centralised: a dedicated team builds and maintains the system.
• Federated: designers and developers from product teams contribute.
• Hybrid: a core team plus contributors, the most common model at scale.

Contribution

Define how teams propose new components or changes: raise a need, check for existing solutions, gather evidence, design and build, review for quality and accessibility, document and release.

Versioning and deprecation

Use semantic versioning (major, minor, patch), clear release notes and migration guides. Deprecate components gradually with warnings and timelines.

Adoption

Make the system the easiest path: good documentation, code examples, support channels and office hours. Measure adoption (component usage across products), quality (accessibility issues, bugs) and satisfaction (surveys of product teams).

Without governance, design systems either stagnate or fragment as teams build their own versions. A healthy system speeds up teams, improves consistency and accessibility and lowers maintenance costs. Treating it as a product with users, roadmap and support is what makes it last.

A company's design system is used by only a third of teams. Others say it lacks components they need and changes break their products without warning. The system team introduces a contribution process, monthly releases with migration guides and fortnightly office hours. Within a year, adoption grows to most teams and several contributed components are added.