Design systems
Design systems that survive a rewrite
Every design system eventually meets the product it was built for, and loses. Not because the system was wrong, but because the product changed shape and the system could not change with it.
We have rebuilt three systems in the last two years, and the pattern is consistent. The parts that survived were not the components. They were the decisions underneath them.
Keep the tokens, question the components
Colour, spacing, and type scales are cheap to keep because they describe intent rather than structure. A button component, by contrast, encodes a particular product idea of what a button is. When the product changes, that idea is usually the first thing to go.
So we keep tokens in a separate layer that no product owns, and treat components as disposable by design. If a component takes more than a day to replace, we usually built it too specifically.
Documentation is the actual deliverable
A system without documentation is a folder of files. What makes it survivable is a short, honest explanation of why each rule exists, what it is for, and what to do when it does not fit. We budget a third of the build time for that writing, and it is the part clients thank us for a year later.
Accept that it will be replaced
The healthiest systems we have built assume their own replacement. They expose a small surface, keep the clever parts isolated, and make the boring parts obvious. When the rewrite comes, the team can move without archaeology.