Development & Code · master area
Component Development
Build the component in Storybook before wiring it into the page. Every state has a story; every state has a visual baseline; every state has a test. The component exists in the catalogue before it exists in the feature.
Owners: 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
- How We Build · Domain Language and Composition — composition canon
- How We Build · Design Execution — where the component meets the surface
How to do this
- Practice — open Storybook first. If the component or state doesn't exist, create the Storybook entry before wiring it into the feature page. The team reviews the component in isolation.
- Practice — every state from the wireframe becomes a Storybook story (idle, hover, focus, loading, success, error, empty). Visual regression baseline captures each.
- Related craft — Storybook
What good practice looks like
A new component is born in Storybook with seven stories before it is consumed once. Its props are named in domain language (exam not data; onGrade not onChange). Its states are explicit (status: 'idle' | 'grading' | 'graded' | 'error'), not implicit boolean flags that combine into illegal states. Each story is its own visual baseline — silent drift is caught at the component level, not at integration.
When the component lands in the feature page, it is already documented, tested, and pixel-stable. Components written inline in feature pages eat the system from the inside — they look like one-offs and become two-offs and accumulate into a parallel design system nobody catalogued.
Related crafts
- Storybook — the catalogue this populates
- Design System — the rules
- Unit Testing — the per-state behaviour test
- Visual Regression Testing — the per-state pixel guard