A design system is a distributed system
Tokens, versioning, breaking changes and consumers you do not control. The hard parts are release engineering, not components.
The components are the easy part. The system part is that a dozen teams depend on your package, they upgrade on their own schedule, and a change you consider a fix is a visual regression in somebody's checkout flow. Every decision therefore has a release dimension: how does this land, who has to do work, and what happens to the apps that do not upgrade for six months.
Tokens are the layer that makes change survivable. Semantic names, surface, border-strong, text-muted, mapped onto primitives, so that a rebrand or a dark theme is a remapping rather than a search-and-replace across every repository. Components consume the semantic layer only. The moment a component references a raw hex value, it has opted out of every future theme.
Version deliberately and deprecate visibly: additive change in a minor release, behaviour or markup change in a major, a codemod when you can write one, and a deprecation that logs in development with the replacement named. And keep the boundary tight: a system that absorbs one team's bespoke pricing table becomes the place changes go to queue, which is how design systems acquire the reputation of slowing everyone down.
You should now be able to
- Design a token layer that survives a rebrand
- Version a component library without breaking every consumer at once
- Decide what belongs in the system and what does not
Loading…