Storybook for component catalogues
A catalogue of your real components, in their real states, that designers and engineers can both point at. It earns its upkeep where several teams or apps share components, and the test is who consumes them.
01Overview
A workshop for building interface parts in isolation
Storybook is an open-source workshop for building and documenting interface components outside the application that uses them. Each story renders one component in one state, with live controls, plus add-ons for documentation, interaction tests, visual snapshots and accessibility checks. It works with React, Angular and others. Your users never load it.
02Capabilities
Three jobs, and only one is documentation
What we actually get out of one, in the order the value usually arrives.
- Contract
The contract between design and code
Design review happens on the components that exist, in the states they have, instead of on a screenshot of the happy path. That is the whole value: the argument about whether the disabled state is right becomes a thirty-second conversation in front of the real thing. It is where a design system stops being a document.
- Inventory
Taking stock of an inherited front end
Cataloguing what is already there is the fastest way to see a codebase's true condition. Nine button variants and four date pickers say more about a product's history than any document, and they scope the modernization honestly.
- Checks
Automated checks at the part level
Interaction tests that click through a component's behaviour, visual snapshots that catch unintended changes, and accessibility checks that run per component rather than per release. This feeds our QA and test automation practice rather than replacing it.
03Fit
Six situations, and whether the upkeep pays
There is an upkeep cost and it is paid by the same engineers who are shipping features. Row one is the case it was built for. Three rows name what answers a different question, and two name the lighter setup or the owner it needs first.
| Your situation | What we recommend |
|---|---|
| A component set consumed by several apps or teams | Use StorybookThe case it was built for. It pays for itself in the duplication that never gets written in the first place. |
| One app, one small team, a dozen components | One internal routeA single internal route that renders every component is nine tenths of the value for a fraction of the upkeep. |
| The real problem is inconsistent design decisions | Different pageDesign system work first, often with product design beside it. Cataloguing inconsistent parts produces an excellent record of the inconsistency. |
| You need confidence across browsers and real devices | Different pageBrowserStack or an equivalent device cloud. Stories render in whichever browser you happen to have open. |
| You need user journeys tested end to end | Different pageBrowser automation against the running application, with TestCafe or Selenium. Stories exercise components, never a checkout. |
| Nobody will own keeping the stories current | Owner before storiesA stale catalogue is worse than none. People trust it and build against components that stopped behaving that way months ago. |
Scope
What we own when we set one up is that last row. Stories get written with the component rather than afterwards. The build runs in CI, so a broken story fails like a broken test, and we mark which components are canonical. unicrew has been building shared front-end component sets since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system.
04Case studies
A build where one set was shared across many apps
One published system where a modular family of warehouse apps drew on a single component set, which is the shape where a catalogue earns its keep.
See all case studies
05Stack
What runs beside it
The tools on either side of a catalogue, each with a page of its own.
06Questions
Questions about the upkeep
Answered the way we would answer them live. If yours is not here, it is a good first message.
Two halves of one contract, and neither replaces the other. Figma holds the intent: what a component should be, in the designer's terms. Storybook holds the reality: what it does, in code, in every state, including the ones nobody drew. When they disagree, Storybook is right about what your users experience and Figma is right about what was agreed.
When more than one person or one application consumes the components, and that is the test we apply rather than a checklist. For a single team on a single app, a plain internal page that renders every component gives most of the benefit at a fraction of the cost.
No. Interaction tests in Storybook cover component behaviour: does this field show its error state, does this menu close on Escape. They say nothing about business logic, API contracts or a full user journey, and a green Storybook alongside a broken checkout is entirely possible. It is one layer inside a wider test automation strategy.
Yes. A Storybook build is static, so it can be hosted anywhere and read by designers, product managers and support without anyone running the app locally. That is often where most of its value comes from: it makes the interface reviewable by the people who have opinions about it and no development environment.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and only after the first read, because a fixed number on a codebase nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Parts of your product drifting apart?
That is a design system problem before it is a tooling problem. Tell us how many apps and teams share your front end, and we will tell you where a catalogue pays for itself. Our side of it is design systems.