A component library is not useful just because it exists. Product teams need to find the right pattern, understand how it behaves, and trust that the coded version will work.
When something is missing, teams make local versions.
Audit real use
I keep one inventory across Figma, code, and products. Each row records the component, where it is used, known issues, evidence, owner, and next action.
The next action is limited to keep, improve, merge, or retire. That turns the audit into a backlog we can prioritise.
I add evidence from repository checks and conversations with designers and engineers. I also record what teams call a component. If the library uses a different name, the documentation needs to support both.
Connect design and code
For each component, I compare its name, properties, states, and behaviour across Figma, code, and Storybook. I add any differences to the inventory rather than leaving them in review comments.
The documentation covers when to use it, available properties, content, accessibility, edge cases, and live examples. Storybook lets teams test those examples without opening the source code.
Contribution requests use the same evidence. They start with the problem, affected products, current workaround, and required states. Larger changes are tested with more than one product before becoming shared.
I track product usage, local overrides, repeated support questions, and contribution requests. Fewer workarounds and fewer repeated questions tell me more than the number of published components.
A system gets adopted when it removes work from product teams.