Design systems that stay simple
Most design systems fail by growing. The useful ones are maintained like gardens — pruned more often than planted.
Every design system I have audited had the same problem, and it was never a missing component. It was surplus: four button sizes where two were used, nine grays with three jobs, tokens named after the meeting they were invented in.
Systems grow by default
Adding to a system feels like progress and costs nothing today. Every addition, though, is a decision future designers have to re-make — which of the four sizes? which gray? — and re-made decisions are where consistency dies.
The systems that stay useful treat additions the way good editors treat sentences: guilty until proven necessary.
Three pruning rules
First, anything unused for a quarter gets deleted, not deprecated. Second, any token that cannot be explained in one sentence gets renamed or merged. Third, every new component must name the existing component it failed to be — if it cannot, it does not ship.
A system maintained this way stays small enough to hold in your head. That, not the component count, is what a design system is for.