Design & UX · master area

Storybook

The design system in code. Every named state has a Storybook entry; every Storybook entry has a Figma frame. The runnable catalogue the team checks before adding a new component.

Owners: Designer, Developer Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: Design-with-the-system, not design-for-the-system.

Where it lives in the chain

• What We Build · Design system and stories — where the catalogue is referenced from
• How We Build · Testing as Chain Verification · QA craft — visual regression hangs off Storybook

How to do this

• Practice — before pulling a story, open Storybook; if the state you need isn't there, the story shapes a system update first
• Practice — review by reading the Storybook entry alongside the Figma frame — they should be one-to-one
• Related craft — Visual Regression Baseline

What a healthy Storybook looks like

Every component in the design system has an entry. Every entry has its states as stories: idle, hover, focus, disabled, loading, success, error, empty. Every entry has a Figma cross-reference in the description — the frame URL, not a screenshot. No story is dead — if the component is removed from production, its story is removed from Storybook the same PR. A Storybook that has 200 stories and a codebase that uses 80 components is a Storybook that has stopped being a source of truth.

The discipline is: the team reaches for Storybook before reaching for Figma when implementing. If they don't, the design system is decorative. The team trusts the catalogue when the catalogue stays honest.

Related crafts

• Design System — the source the catalogue renders
• Visual Regression Baseline — the silent-drift detector hanging off Storybook
• Component Development — the code half