What is the perfect design system flow?

The story is the canonical artifact

A Storybook story is both code and design. It runs as real React — props, interactivity, types. It’s also a curated visual artifact: named for its purpose, isolated from business logic, rendered in Storybook for review.

That dual nature is what makes it the canonical place where design and code meet. Engineers author it because it’s code. Designers review and reshape it because it’s visual. PRs and types keep both honest.

Figma becomes a view of stories. Production code is a view of stories. The story itself is the canonical thing.

The loop, in two shapes

Once the story is canonical, every change has to land there. There are two shapes the loop can take, depending on how big the change is.

Plugin round-trip — for surgical edits

When a designer changes a token in Figma — a color, a spacing value, a corner radius — the plugin captures the diff and opens a pull request against your stories. Review, merge, and the next Figma regenerate is built from the new tokens. Today, this works for tokens on the Free tier. Structural component edits (layout, variants, copy) are the active Pro track and use the same shape.

Until the structural Pro track ships, structural edits to existing components follow the manual path described below — same workflow as a new component, just editing the existing story file instead of creating a fresh one.

Figma → PR → Code → next regenerate → Figma view refreshes.

Designer-led re-implementation — for new components and redesigns

When the change is bigger — a brand-new component, a major rework, a redesigned variant — the designer drafts it in Figma as a spec. An engineer implements it as a Storybook story, either by hand from the Figma reference or by bootstrapping a first draft with an AI coding agent and the Figma MCP, then refining from there. The designer reviews live in Storybook. Once approved, the plugin regenerates the Figma design system page and the new component is canonical in both views.

Figma spec → story authored (by hand or AI-assisted) → Storybook review → plugin regenerates Figma view.

The principle holds in both shapes. The story is what gets merged. The plugin is what makes the Figma side cheap enough that you don’t have to maintain it by hand.

Design and code, identical

The Figma design system Inkbridge generates is built from the code. The component a designer reviews in Figma is the same component that ships to users — same Tailwind classes, same spacing scale, same colour tokens, same states. No translation step, no developer interpretation, no approximation.

The handoff is the same as any workflow up to implementation: the designer shows the Figma design to stakeholders, gets sign-off, hands off to engineering. The shift happens after. The designer reviews the implemented component live in Storybook and confirms parity. From that point on, stakeholders see the real thing — Storybook for individual components, the live page for full screens — and what they see matches the design that was approved, because the Figma design system was generated from the same code that’s running.

Accessibility, types, and tests come along for free, because they ride on the story. Every new story makes the design system bigger, not noisier.

Why we built a plugin

We wanted to live in this flow ourselves. To make it work, we needed a plugin that reads stories the way they were written — your conventions, your Tailwind classes, your component composition — and renders Figma from the story’s intent rather than a screenshot of it. Edits should flow back as pull requests you can actually review. So we built that.

The full loop — generate, token round-trip, AI-assisted bootstrap — is on the Free tier, because the methodology is the point. Pro is one experimental piece: structural component edits flowing back as JSX and Tailwind diffs.

Go deeper

The technical deep-dives live under /docs/methodology — one page per piece of the loop, written for engineers and designers who want to apply the methodology to their own stack.