Documentation

Question 1

How many of your released components have usage documentation (what it is for, when not to use it, props/API)?

Coverage of usage docs is the single strongest predictor of whether teams adopt a component without asking the core team.

Question 2

Do you document design guidance (do's and don'ts, content and layout rules) alongside the code API?

Prop tables tell developers how to call a component. Guidance tells everyone when it is the right one.

Question 3

Is accessibility behaviour documented per component (keyboard interaction, roles, known limitations)?

Undocumented a11y behaviour is re-implemented — usually incorrectly — by every consuming team.

Question 4

Can someone see and interact with a live example of a component without cloning your repository?

A running example removes the largest single barrier to trying a component.

Question 5

Is there a written getting-started path for a new team that wants to use the design system?

Install, theme, first component, where to ask — the four things every new consumer needs on day one.

Question 6

How do you keep documentation from going stale as the code changes?

Stale documentation is worse than none: it is trusted and wrong.