I have worked with component libraries that looked impressive in Storybook and barely changed how product teams worked. A useful design system has to do more than collect components.
For me, success looks fairly ordinary: less repeated debate, fewer one-off solutions, and a clear default when a team starts a new feature.
Components are team agreements
A component API tells designers and engineers what the common case looks like. Good defaults make that case easy. Variants cover real product differences without turning every prop into a new design decision.
When a team needs an exception, it should be easy to spot and discuss. Examples, accessibility notes, content guidance, and the reason behind a pattern matter just as much as the code.
Keep Figma and code in step
Figma, the code, Storybook, and written guidance each answer a different question. They do not need to contain exactly the same information, but they do need to describe the same product language.
Once they drift, people pick the source that suits the decision they already made. Keeping them in step makes the system dependable instead of optional.
Look at the work, not the component count
I pay attention to how quickly a team finds the right pattern, how often it needs a local exception, and whether a fix in one place reaches the other products that need it.
Those signals tell me more than the number of components. A design system is working when it helps with today’s feature and makes the next one a little easier.