Design systems that don't slow you down
How to build a component library teams actually adopt — tokens, variants, and the ShadCN approach.
Most design systems fail the same way: they optimize for the system's internal elegance instead of the team's daily speed. The result is a library everyone is required to use and nobody wants to.
The ShadCN model flips this. Components live in your repo, not in node_modules — so when a component doesn't fit, you edit it instead of fighting its API or forking the package. Ownership beats abstraction.
Tokens are where systems earn their keep: a small set of semantic CSS variables (background, foreground, primary, border) means dark mode, theming, and rebrands are one-file changes. Resist the urge to tokenize everything — twelve tokens used consistently beat two hundred used sometimes.
Adoption is a product problem: make the system path the fastest path. If using the button takes longer than writing a div with classes, the system has already lost.