Review the implementation in Storybook

The designer-side validation step: how a designer signs off on a component by reviewing the running Storybook, not the Figma mockup.

When this applies

Almost every other deep-dive in the methodology ends with the same step: a designer reviews the implementation. This is that step, documented once so the other pages don’t have to repeat it. It applies after:

A new component is implemented from a Figma frame (by hand or AI-assisted).
A token round-trip PR lands and the designer wants to see how the new colour or spacing looks across the existing components.
A structural component edit ships (eventually — currently the Pro research track).

Why review happens in Storybook, not Figma

A Figma mockup is a designed intent. A Storybook story is the running code that ships to users. When a designer reviews in Figma against another Figma frame, they’re comparing one approximation against another. When they review in Storybook, they’re comparing the actual running thing against the spec.

That distinction matters because once the implementation lands, the code is what gets shipped to users — not the mockup. If the running Storybook matches the design intent, what users see will too. If it doesn’t, no amount of Figma polish on the original mockup will fix it.

The Figma design system Inkbridge generates is a view of the same stories. So it’ll always agree with Storybook (post-regenerate). Reviewing in Storybook just gets you to that ground truth one step earlier.

The review flow

1. Open Storybook on the PR branch

Either run it locally (pnpm storybook) checked out to the PR branch, or use a deployed preview if your CI ships one (Vercel/Netlify previews on Storybook builds, Chromatic, or the deployed Storybook URL the engineer shares in the PR description). The PR comment should always name the story to open.

2. Navigate to the story

Stories are named after their visual state — Default, Open, Loading, Error, WithIcon, Disabled. Find the relevant ones in the Storybook sidebar. Each state is a separate story; the implementation should have one per state the design specifies.

3. Compare against the spec

Put the Figma frame next to the Storybook canvas and check the obvious things first:

Visual parity — colours, spacing, radius, typography, shadows, borders. The token system covers most of this automatically, so anything off here is usually a wrong token reference, not a wrong value.
Interaction states — hover, focus, active, disabled. Each one should have its own story; you don’t need to hover over a single story to find the states.
Responsive behaviour — Storybook’s viewport addon (or the responsive previews on the Figma design system page) shows what the component looks like across breakpoints.sm, md, lg, xl should all behave like the design.
Content edge cases — long strings, missing data, truncation. The story should cover the cases the design considered; if it doesn’t, that’s a missing story.

4. Sign off or request changes

Comment directly on the PR. Reference the story name, not Figma frame coordinates:

PR comment

Button > Disabled story: the foreground is reading as full
opacity, should be 60% per the design. Probably needs the
disabled: state class.

The reviewer never opens Figma to point at things — they reference the canonical artifact (the story), say what’s wrong against the design, and let the engineer fix it. The next push triggers another review round on Storybook, not on Figma.

What changes once this lands

The biggest shift is cultural, not procedural. Once designers internalize that Storybook is the validation surface:

Figma mockups become specs, not sources of truth. Designers stop annotating them as if they were the final artifact.
Design QA happens before merge, not after deploy. Bugs caught in Storybook never reach production.
The handoff conversation simplifies. Instead of “the Figma says X, the code does Y, which is right?”, it becomes “the story shows Y, the design intent was X, fix the story.” The story is the canonical thing both sides agree on.
Designers gain real confidence about what ships. They review the running thing; what they sign off on is what users get.

What doesn’t change

Up to implementation, designers work in Figma the way they always have — exploring, iterating, getting stakeholder sign-off on the design intent. The shift is only at the review step: the question “does the implementation match my design?” is answered by looking at the implementation, not by comparing two mockups.

← Back to Methodology