Design & UX · master area

Design System

Tokens, components, patterns, rules. One library, two surfaces — the Figma file and the codebase — kept one-to-one. The team's shared language for shape.

Owners: Designer, Developer Phase it lives in: What We Build → How We Build (Volumes III and 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 — the canon
• How We Build · Design Execution — where the system is consumed at full fidelity

How to do this

• Practice — review the Storybook before pulling a story; if the component you need doesn't exist, the story changes shape
• Clinic — A retro that listed — "improve consistency" without naming a token is feelings
• Principle — Chain-level thinking

What a healthy system looks like

One source for tokens (colour, spacing, type, radius, motion) consumed identically by Figma and the codebase. Components named the way the team speaks — PrimaryButton, not LargeBlueButton/Variant3. Every component has a Storybook entry with its states named: idle, hover, focus, disabled, loading, error. Every component has a visual regression baseline so silent drift becomes a build failure, not a bug report. A design system the team can describe in two minutes is a system that's working. A system that needs a 40-page document is a system that's already drifting.

The discipline is one-to-one: what the Figma library can render, the codebase can render — and vice versa. When a designer adds a frame the system doesn't support, that is either a system update (planned) or a deviation (named, dated, owned). Silent deviation is technical debt the next cycle pays for.

Related crafts

• Storybook — the runnable catalogue
• Design System Governance — how the system evolves
• Component Development — the code half
• Visual Regression Baseline — the silent-drift detector