A component library a product team actually uses
What made a shared React + Storybook component library stick on a fast-moving product, and what made earlier attempts get ignored.
Why most libraries get ignored
On a trading-platform frontend, the first shared components were built ahead of the screens that needed them. They looked good in isolation and missed what the real screens needed, so developers kept writing their own.
Extract, don't invent
The version that stuck grew out of real screens. A component moved into the library when a second screen needed it, with the props both screens actually used. Nothing was added for a hypothetical third use.
Storybook as the contract
Every component has stories for its real states: loading, empty, error, long content, disabled. Reviewers check the story, not just the code, and designers compare it with the design file.
export const Loading: Story = { args: { rows: [], loading: true } };
export const Empty: Story = { args: { rows: [] } };
export const LongContent: Story = { args: { rows: manyRows } };Tokens before components
Colours, spacing and type sizes live in one theme. Components only use tokens, so a brand change is a theme change, not a search-and-replace across hundreds of files.
Keep it boring
No clever abstractions, clear prop names, and a changelog. The best compliment a component library gets is that nobody thinks about it.