GOV.UK Design System: guidance backed by research
The GOV.UK Design System is the one I'd show anyone writing component documentation. Each component page says when to use it and when not to, and shares what the team has learned from research with real users. It reads like advice from a colleague, not a list of properties.
What to borrow: write down what you've learned from testing your components, and put it on the component page.
IBM Carbon: accessibility on every component
Carbon gives accessibility its own section on each component page, separate from usage and code. It says what the component already handles and what the team using it still has to do.
What to borrow: make it clear, for every component, which parts of accessibility the system handles and which parts are the product team's job.
Material Design 3: tokens that drive themes
Material Design 3 is built on tokens at different levels, from the full palette, to roles like primary and surface, to the values each component uses. That's what lets it change a whole theme from one source.
What to borrow: a layer of semantic tokens between your palette and your components, so a theme change doesn't mean touching every component.
Atlassian: one system across a lot of products
Atlassian runs one design system across a lot of products built by different teams. Its tokens, components, and guidance are what keep those products feeling like one family.
What to borrow: if your system has to work across several products or teams, invest in shared tokens and clear contribution rules before you add more components.
Gideon Awolesi