Design systems don't fail because of tokens
They fail at the boundary between the people who name things and the people who ship them.
Staff design systems engineer at Stripe
Every design system post-mortem I have attended contains the same sentence: we had the tokens, but adoption stalled. Tokens are not the system. They are the vocabulary. Adoption is a social problem wearing a technical costume.
The first failure is naming. A token called color-surface-subtle means something to the person who wrote it and nothing to the engineer choosing a background at 5pm on a Thursday. We renamed ours after the job: page, card, inset, emphasis. Boring names get used.
The second failure is ownership. When the system team owns every component, product teams wait in a queue. When product teams own their variants, the library splits within a quarter. The version that works is a small core owned centrally and a documented escape hatch owned locally.
The third failure is documentation without migration. A changelog is not a migration guide. If you cannot show a team the exact diff that removes their deprecated component, they will keep the old one until it breaks.
Measure adoption in migrations completed, not components published. The dashboard that matters shows how many teams moved off the old API this month. Everything else is inventory.
Conversation
2Boring names get used — that is the entire battle, honestly.
The migration diff point is underrated. We stalled for a year on exactly that.