When Figma and Storybook drift apart, which tools actually help?

When the Figma button and the Storybook button disagree, the first question is not which tool to add. It is which of the two is right, and no tool on this page can answer that. What tools can do is make a difference visible, or cheap to fix, at the moment someone changes one side. This page groups them by that moment.

Tcules does not sell or resell any tool named here and has no affiliate relationship with their makers. Features, plans and prices come from each vendor's own pages and documentation, checked on 13 October 2026. They change; confirm them before you commit. Two tools that Tcules publishes are mentioned separately and labelled as ours.

No tool decides which side is right

Every tool in this space does one of three jobs:

• Link. Put the other representation one click away: a story inside Figma, a Figma frame inside Storybook, real component code inside Dev Mode.
• Compare. Report a difference: between a component and its last approved version, or between a build and a Figma frame.
• Generate. Make one side a copy of the other, so there is nothing left to compare.

Only generation keeps the two aligned without a person, and it does so by ending one side's independence. The documentation for story.to.design, which builds Figma components from stories, tells designers not to edit the components it generates, because edited components lose their connection with code. That is a decision about authority, delivered as a tool.

Linking and comparing tools stop short of that. Chromatic's documentation for its Figma plugin is explicit that a Figma change does not start anything on the code side: someone has to change the code and run a new build. Figma's help pages describe Code Connect as showing design system code in Dev Mode, not as checking that the code matches the design.

Survey data points the same way, with a caveat. In zeroheight's Design Systems Report 2026, 60% of 147 practitioners reported no automation for design tokens at all, and 5% reported two-way sync between design and code. Respondents listed design-to-code parity checks among the things they wish they could automate. The sample is self-selected and the publisher sells documentation software; the figures are about tokens, the most automatable layer, not components. Our inference is that component-level alignment is at least as manual.

So the useful question is where a comparison appears. In our judgement, the tools worth setting up are the ones that show the difference to the person making a change, while they are making it: in the design file, in the pull request, in the review. A difference found in a quarterly audit can already have been built on by then.

Decide what governs each difference before you add tooling

Teams answer "which is right?" in three ways. Some treat code as the reference: Brad Frost has argued that the true source of truth for a design system is its coded components, with the Figma library there for designer efficiency. Some let Figma lead, so new behaviour is designed first and code catches up. And some, as Christine Vallaure proposed in July 2026, keep a third artefact, a component contract, and generate both sides from it.

Each is workable. What fails is leaving it unstated, because then every tool on this page reports differences that nobody has the authority to close. The Tcules position is that authority is best decided per kind of difference rather than for the whole system:

A legitimate difference can stay, provided it has an owner and a reason. The tools below make a recorded decision cheaper to keep. They cannot make one.

Tcules publishes a Figma to Storybook Fidelity Checklist for recording this per component. It is our own tool, and it counts mismatches and gaps by kind rather than averaging them into a fidelity percentage.

When a designer changes the Figma library

The aim at this moment is that the people who own the code find out, and that the designer can see what the code currently does.

Dev Mode statuses and Compare changes (Figma). A designer can mark a frame or component ready for dev. If a design marked ready or completed is later modified, Figma sets a Changed state automatically. Developers with a Full or Dev seat who have viewed the file in Dev Mode are notified when a design is first marked ready for dev and, on Organization and Enterprise, when the designer marks the changes done; the Changed state itself sends no notification. Ready for dev is on all paid plans; the Completed status needs Organization or Enterprise. Compare changes then shows the old and new versions side by side, with property values from each, and can compare a detached component or overridden instance with its main component. This tells engineers the design moved. It does not tell them whether the code already differed.

Library publish webhooks (Figma REST API). Figma's `LIBRARY_PUBLISH` webhook event lists the components, styles and variables created, modified or deleted in a publish. A small service that turns each publish into an issue for the component owners puts the change in the engineering backlog rather than in a notification someone may miss. You build and host the receiver yourself. Webhooks are part of Figma's REST API, which documents webhook limits by plan and by context (team, folder or file).

Storybook Connect (Chromatic's Figma plugin). The plugin links stories to Figma components, variants and instances and shows the latest build of the linked story, from the branch you choose, inside Figma. A designer changing a component can see what the coded version does now, including interaction, without leaving the file. It needs a Storybook published to Chromatic, edit access to the Figma file and collaborator access to the Chromatic project. Chromatic's pricing page lists the plugin on every plan, including Free.

Check designs (Figma). Check designs flags hard-coded values that could be variables or styles, and components from the wrong library, one page at a time. It is available on Organization and Enterprise plans. It checks the Figma side against the Figma library, not against code, but a design full of detached values is hard to compare with anything.

When a developer changes a component in a pull request

The aim here is that a change to the coded component is seen by someone who knows the design intent before it merges.

Visual tests and UI Review (Chromatic). Chromatic captures each story and, in UI Review, compares the latest commit on the pull request with the commit it branched from. Teams can set default reviewers, so a designer is assigned automatically, and can make the review a required check in GitHub, GitLab or Bitbucket. On Chromatic's pricing page, visual tests and UI Review are on every plan: Free includes 5,000 billed snapshots a month, Starter is $179 a month for 35,000, Pro is $399 a month for 85,000, and Enterprise is priced on request.

One limit matters for drift. This comparison is code against the code's own past, not against Figma. It catches an unintended change. It does not catch a difference that was already in the baseline, and approving a change makes it the new baseline.

The Figma design beside the story. Two ways put the design where the reviewer is already looking. Storybook's own designs addon embeds a Figma file, frame or prototype in a panel next to the story; it is open source, and its current release supports Storybook 10. Figma in Chromatic shows a linked Figma component in a Designs tab in Chromatic's component library, where layers can be inspected; it accepts component links, not frames or layers.

Code Connect, maintained in the repository (Figma). Code Connect links Figma components to code components so Dev Mode shows real usage code. It is available on Organization and Enterprise plans with a Full or Dev seat; Figma's pricing page lists Dev seats at $25 a month on Organization and $35 a month on Enterprise, billed annually. There are two ways to create mappings, and the difference matters here. Mappings made in the Code Connect UI live in Figma and do not yet support property mapping. Mappings made with the CLI live in your repository and map Figma properties to code props, so a change to the mapping appears in a pull request like any other code.

The CLI's publish step validates Code Connect files against the Figma API unless you skip validation, and a mapping that names a property the Figma component does not have fails with a property-does-not-exist error. Our inference: a team that publishes from CI will see a failed run when a mapped Figma property is renamed or removed. That is a narrow check. It covers the properties someone chose to map, not appearance or behaviour, and we have not measured how completely it catches other changes.

If your team used Code Connect's Storybook integration, note the recent change. Code Connect 2.0.0, released on 18 August 2026, restricts framework-specific parsers, including the Storybook integration, to migration and unpublishing. Template files are now the only maintained format, and the CLI includes a migrate command.

Checking the build against the design directly

A few tools compare the built component with Figma itself rather than with the code's history.

Figma baselines in visual tests (Applitools). Applitools lets a test use a Figma frame URL as its visual baseline, so the check compares your build with the design. Its earlier export plugin offers several match levels, such as Strict, Layout and Content, and its documentation says the plugin will be deprecated in favour of the newer workflow. Figma design integration and Storybook component testing are listed in the Starter plan at $667 a month, paid annually; higher plans are priced on request.

Agent-run parity checks. Figma Console MCP, an open-source MCP server from Southleft under the MIT licence, includes a tool that compares a Figma component's specification with its code implementation and returns a scored list of differences. Its setup depends on the mode: the local mode needs Figma Desktop, a companion plugin and a personal access token, while the remote mode uses OAuth. It is run by an AI agent at someone's request.

Both are appealing, and both carry the same limits. A frame comparison only covers the states someone drew, at the sizes they drew them, and it checks appearance rather than behaviour. A frame that is out of date turns a correct build into a failing one. A parity score can help decide where to look first, but the score does not say which side should change; that is why the Tcules checklist counts mismatches by kind rather than producing a percentage. In our judgement these checks are worth their cost where Figma frames are kept as exact, current specifications for the states you test, and not otherwise.

When a coding agent builds the interface

Agents now read both sides. Figma's MCP server gives coding agents design context; the remote server is available on all seats and plans, and writing to the canvas is free during its beta and expected to become a usage-based paid feature. Figma's developer documentation says Code Connect makes generated code reuse your actual components. Storybook's MCP server, in preview, gives agents component documentation and lets them write stories and run tests; its development and testing tools work in any Storybook project, while its documentation tools currently cover React frameworks and the Vite builds of Angular and Vue.

This does not reduce the need to decide which side is right. It raises it. If the Figma component and the Storybook documentation describe different behaviour, an agent connected to both receives two instructions and will follow one of them, repeatedly. Our judgement: settle the components your agents use most before connecting either server, and prefer Code Connect mappings over unmapped Figma frames, so the agent is pointed at the component that already exists.

Making one side a generated copy of the other

If the team has decided that one side governs, generation removes a whole class of comparison.

Code to Figma (story.to.design). story.to.design generates Figma components and variants from your stories and tells you when the code changes, so you can review and pull the update into Figma. Its homepage says it works with any story framework, and its documentation and blog describe support beyond Storybook. The Team plan is listed at $149 or $199 a month depending on billing period, for one Storybook and unlimited users; the Agency plan is priced on request. The trade is the one described above: designers stop editing those library components directly and propose changes elsewhere.

Both sides from a contract. The contract approach generates Figma variants and code from one specification and checks that both still agree with it. It is a way of working rather than a product, and it moves the design discussion into editing the contract.

Tokens. Token pipelines generate values on one side from the other, and they remove the most mechanical differences. They are covered in our wider article on design system tools for SaaS teams. One constraint to know early: Figma's Variables REST API requires an Enterprise plan.

The tools at a glance

Listed by the moment each tool serves, not ranked. Plans and prices were checked on 13 October 2026 from the linked vendor pages.

Which are worth the setup

This depends less on the tool than on what you already run and what you have decided. Our judgement, by situation:

• Everyone, first. Record which source governs names, properties, states, behaviour and versions for the component families in dispute. It costs meetings rather than licences, and without it every tool reports differences nobody can close.
• You already publish Storybook to Chromatic. Link the disputed components with Storybook Connect and add a designer as a default reviewer in UI Review for the component library. The extra setup is small, because the plugin is on every plan. Remember that the visual test compares code with code.
• You are on Figma Organization or Enterprise, and engineers or agents work from Dev Mode. Maintain Code Connect with the CLI in the repository, using template files. The ongoing cost is a template per component and upkeep when either side changes, as the August 2026 breaking change showed. The benefit is that mappings are reviewed like code and agents are pointed at real components.
• You are on Figma Professional. Code Connect is not available. Ready for dev with change notifications, the designs addon in Storybook and, if someone can host it, a library publish webhook give you most of the "someone finds out" value.
• Your Figma frames are exact and current for the states you care about. A direct comparison such as Applitools Figma baselines may be worth trialling on one component family. If the frames are not kept current, you will spend the time triaging stale pictures.
• You have decided code governs visual form, and designers agree. Generating the Figma library from stories removes the visual comparison for those components. It does not settle behaviour.
• You are curious about agent-run parity checks. Try one on a single disputed component and treat the output as candidates for a person to decide, not as a verdict.

What these tools leave unchecked

Two things fall between every tool above.

Behaviour. A select can match Figma pixel for pixel and still trap a keyboard user; a save button can show the right spinner and submit twice. Visual comparison, in either direction, does not see this. Storybook's testing guidance treats interaction and accessibility as separate checks from appearance, and its accessibility testing page says the automated checks catch up to 57% of WCAG issues and flag incomplete results to confirm manually. The Tcules Figma to Storybook Fidelity Checklist, our own tool, records those behaviour checks per component.

The version a product actually uses. Figma and Storybook can agree while a product ships a copied or outdated component. None of the tools above follows the component into the consuming product. The Tcules Design System Drift Checker, also our own, traces one component family across Figma, code and a running product.

We have also left out tools that generate new code from Figma designs. They serve a different job, producing a first implementation, and can add a third version of a component rather than aligning the two you have. Keeping a build true to the design from the first implementation is the subject of How do I keep my React build true to the Figma design? Documentation platforms and token tooling are covered in the wider tools article.

This work sits between design intent and the running component

When the Figma library and the coded components disagree and nobody can say which is right, the missing piece is likely to be the decision record, not another integration. The Tcules Figma and Storybook alignment work compares the real component across both, resolves each difference with an owner, and sets up the review points that keep it resolved. If the disagreement spans design, code and the running product, a Design-to-Code Audit reads the current state first. The vocabulary for unintended divergence, as opposed to supported variation, is in our definition of design system drift.