Notes on building a design system you'll actually use

Most design systems fail not because the components are bad, but because the activation cost of using them is higher than the cost of not.

Three rules we hold ourselves to: ship the system as a dependency the same week the first product feature uses it; require code review on token changes the way you require it on payments code; and make the documentation site faster to load than your IDE.

Treat consumers like product users — they have alternatives. The alternative to your <Button /> is a styled <button>. If your <Button /> takes 14 props and a wiki to use, the styled <button> wins. Every time.

Constraint, not coverage. The best design systems are smaller than people expect.