Design systems that survive redesigns

Design systems are easy to start and easy to kill. The kill usually arrives in the form of a new design leader who says, kindly, that the system feels dated. Within two quarters the Figma file is forked, the tokens are out of sync, and engineers are back to copying styles between files.

Here's what we've found makes a system survive that conversation.

Tokens are the contract. Components are not.

When a new designer wants to make changes, they should be able to repaint the entire product by editing tokens. The components are the substrate; the tokens are what gives a product its visual personality. Build for the token swap.

Document what the system is for, not how it works

The README should answer: when do I reach for this component? When do I not? What problem was it designed to solve? Engineers and designers will figure out the props.

Version the system like a library

• Semantic versioning so consumers know what's breaking.
• A changelog that reads like a release note, not a commit log.
• Codemods for breaking changes. Don't make consumers do the work twice.