Some things I've learned about design systems

This post is partially inspired by an episode of a new design-systems-focused podcast: On Theme: Design Systems In Depth.

In no particular order:

1. Avoid being an “everything” system - that’s for HTML and CSS to handle
2. Have specific, justified solutions to existing product problems
3. Pick your battles; expansion for expansion’s sake will crush your team output
4. Design tokens are complicated - don’t introduce them unless you really need to (e.g., enterprise branding support)
5. Sometimes “simple” components can be a cost center (e.g., button)
6. Documentation is for people, not robots (although AI might change that pretty soon)
7. It’s OK to say “no” to things
8. A design system is just design with frills
9. A pattern is useful until it’s not; be ready to drop support for stuff as your product evolves
10. If your component APIs feel confusing, they’re probably confusing
11. Engineers and designers can and should automate across their disciplines
12. Review governance expectations frequently
13. Pair with product designers/engineers (don’t work in a vacuum)
14. Not all design systems need foundations
15. Read about software patterns; they turn out to be really useful for design systems