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. AI agents read the same model over MCP. Production code is a view of stories. The story itself is the canonical thing — every other surface is a consumer of it.

One model, many consumers

Under the hood, Inkbridge is a compiler. It reads your React, Tailwind or MUI, and Storybook code and emits one renderer-agnostic artifact — the Inkbridge Design-System Model: every component, its variants and states, and your tokens, in plain web vocabulary.

Figma is the first consumer of that model, and still the flagship — it’s where designers and agencies work. But it isn’t the only one. AI agents read the same model over MCP, with no Figma in the loop, and write conformant code back. The model is the durable asset; each surface is a backend. Bind your design system to one tool and the next tool is a migration; compile it to a model and the next tool is just another consumer.

That’s the real reason the story sits at the center: it’s the one representation every consumer can be generated from.

The loop, in a few shapes

Once the story is canonical, every change has to land there. There are a few shapes the loop can take, depending on how the change is made and how big it is.

Agent-authored — from the model, conformance-gated

This is what actually closes the loop for most changes now. An AI agent reads the design-system model over MCP — your components, variants, and tokens — generates code that reuses them, and writes it straight back to your project, gated by a conformance check. No Figma in the loop, no button to press. The story file is what lands.

Model (MCP) → agent generates → conformance-gated write → story lands.

Plugin round-trip — for surgical token 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 token source: CSS custom properties for Tailwind projects, theme.ts literals for MUI. Review, merge, and the next Figma regenerate is built from the new tokens. Today, this works for tokens. Structural component edits (layout, variants, copy) are the active research track and use the same shape.

Until the structural research 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 or MUI styles, 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 compiler, not just a plugin

We wanted to live in this flow ourselves. The Figma plugin came first — it reads stories the way they were written (your conventions, your Tailwind classes or MUI theme, your composition) and renders Figma from the story’s intent rather than a screenshot of it. Agencies and designers still lean on it, so it stays the flagship.

But the more we built, the clearer it got that the plugin is one consumer of a bigger thing: a compiler that turns your code into a design-system model any tool can read. That model — not the Figma binding — is the durable asset, and it’s what an AI agent reads over MCP to generate conformant code with no Figma in the loop.

The full loop — generate the Figma view, read the model over MCP, write conformant code back — is free, because the methodology is the point. We didn’t invent that methodology; component-driven development and encapsulated stories are long-standing best practice. Inkbridge is what makes them pay off. One experimental piece is still in development: structural component edits from Figma 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.