How do I keep my React build true to the Figma design?

Insights · Method guide

Last reviewed October 5, 2026.

Agree what "true" means before anyone codes: the decisions, states and behaviors that must survive, not pixel likeness. Then share one set of design values between Figma and code, map each frame to a component with every state built, run automated checks for regressions, and have a person review and accept or correct each remaining difference.

Exporting code from a design is the easy part of Figma to React. Keeping the build true to the design is a process question, because the two files are different kinds of thing: a Figma file shows chosen frames, and a React application has to run for real people, with real data, on real devices. This guide sets out a method that applies whether a person or a coding agent writes the first pass.

What does "true to the design" mean?

Start by separating three things a team can blend together: what the design decided, what it merely showed, and what it never covered.

A decision is something the team would defend: this action stays visible next to its row, this error blocks submission, this panel keeps its priority on a narrow screen. A frame is one picture of that decision at one width with one set of sample content. Everything else (empty, loading, error and permission states, long content, keyboard order) may live in nobody's file.

That gap is not only a developer failing. In a CSCW 2017 paper, Maudet and colleagues ran three studies on designer and developer gaps, including 16 interviews, and reported that current practices led to unnecessary rework and to differences between the original design and the implementation, and identified three breakdowns in which designers omitted critical details, ignored edge cases or disregarded technical limitations. The study is from 2017 and predates today's Figma features, so read it as evidence about where mismatches begin, not about how often they occur now.

In practice, write the acceptance down before the build starts. For each screen or flow, list:

• the product decisions that must hold (not the pixels);
• the states to build, including the ones no frame shows;
• the widths, zoom levels and input methods that count;
• who decides when code and design disagree.

Every later check depends on this step.

How do you keep design values from drifting?

One source of visible drift is a value copied by hand: a hex color, a spacing number, a font size. Each copy is a chance to be wrong, and a copied value is easy to miss in review.

The fix is a single named source for those values, used by both sides. Atlassian's design system documentation describes design tokens as the single source of truth to name and store design decisions. In Figma, variables hold named values; in code, those names become CSS custom properties, a theme object or similar. A build step that turns one file into the other helps keep them aligned.

Two practical notes:

• A standard exists for exchanging tokens between tools. The Design Tokens Community Group published its first stable format in October 2025, and its 2025.10 specification is a Final Community Group Report. It is stable and intended for implementation, but it is not a W3C Standard, so check which format your tools actually support before you commit to it.
• Tokens only help if the components use them. A search for hard-coded colors and spacing values in the codebase is a cheap test of whether the system is really in force. Treat each literal value as a question: a missing token, or a shortcut?

How do frames become React components?

A frame is not a component. Map the design onto the code in two steps.

First, decide the component boundaries. React's own guide, Thinking in React, suggests drawing boxes around the pieces of the mockup, naming them, and looking at the design's layers as one way to split them. It then recommends building a static version first, with data passed in as props and no state, and adding state only where the interface is interactive. That order is useful here: it lets you check the layout and styling against the design before behavior complicates the comparison.

Second, build the states, not the screenshot. In Storybook, each story is one component in one configuration, so a component with default, loading, empty, error, disabled and long-content stories is a visible list of what has been built. The design file can then be checked against that list, and the list is what automated tests attach to.

Figma's own tooling can shorten the handoff, with limits worth knowing:

• In Dev Mode, Code Connect shows a team's own component code on a selected design component instead of autogenerated snippets. Figma's help page lists it as available on Organization and Enterprise plans, so check your plan and seat type.
• The Code Connect documentation maps design properties to component props, and notes that those files are not executed and are treated as strings by the CLI. A mapping shows what a component should look like in use. It does not prove the running component behaves that way.

Which checks catch which differences?

No single check covers the gap. Each one finds a different kind of difference and is blind to others.

Two cautions come from primary sources. Playwright's screenshot testing guide warns that browser rendering can vary with the host operating system, version, settings, hardware and headless mode, and advises running tests in the same environment that generated the baseline. A baseline captured on a laptop and compared in a different CI image can fail for reasons that are not design differences.

Automated accessibility tools find only part of what is wrong. In 2017 the UK Government Digital Service accessibility team tested 10 tools on a page built with 143 known failures. The best tool found 41 percent of the barriers when manual inspection prompts were counted (37 percent for the best tool counting only errors and warnings), and 29 percent were missed by every tool. That was one test page and the tools have changed since, but it supports using automation for repeatable coverage and people for the rest.

A design file also cannot tell you what to test at the edges. WCAG 2.2 Level AA requires content, with stated exceptions, to work at an equivalent of 320 CSS pixels wide (a 1280 pixel viewport at 400 percent zoom) without two-dimensional scrolling, and text to resize to 200 percent without loss of content or function. If the Figma frames are at a few fixed widths, those conditions have to be reviewed in the running build.

What if AI generates the first pass?

Figma's MCP server lets coding agents read design context from a file, including variables, components and layout. Figma's documentation says Code Connect lets generated code reuse the team's actual components. That should reduce one kind of drift, because the agent starts from the real component library rather than inventing markup.

It does not remove the need to verify. Design2Code (Si and colleagues, NAACL 2025), which its authors describe as the first real-world benchmark for this task, tested multimodal models on 484 real-world webpages and found that they mostly lag in recalling visual elements from the input and generating correct layouts. Treat that as neighboring evidence only: the inputs were webpage screenshots rather than Figma files or application interfaces, and the models were those available when the study was run. What it supports is a narrow point: a generated page that looks plausible is not the same as one that matches.

So hold generated code to the same acceptance as hand-written code: the same tokens, the same state stories, the same checks and the same human review. The only thing that changes is how quickly the first draft arrives.

How do you review the differences that remain?

After the checks run, some differences will remain, and not all are defects. Real content, browser behavior, technical constraints or a state nobody had designed can all make code legitimately depart from a frame.

For each material difference, record the product decision it touches, what the design shows, what the build does, the consequence for a customer, and the disposition. Tcules's design engineering page lists five: correct the code, update the design, change the system, document a legitimate difference, or revisit the product decision. The point is to decide deliberately which source is right instead of assuming the design always wins.

Give each accepted correction an owner and a check, ideally automated, so the same difference does not return in the next release.

A checklist for a Figma to React build

Before the build

• Write down the decisions that must hold, the states required and the widths and zoom levels that count.
• Name who decides when design and code disagree.
• Agree on one source for color, spacing, type and motion values.

During the build

• Split the design into components and build a static version before adding state.
• Write one story for each state, including empty, loading, error, disabled and long content.
• Use tokens, not literal values, and search for the exceptions.
• Review the running build at narrow widths, at 200 percent text size and with the keyboard.

Before release

• Run visual regression and accessibility checks in a pinned, repeatable environment.
• Have a person compare the running product with the design for the flows that matter most.
• Record each material difference with a disposition, an owner and a check.

Where this work sits

In search terms this is "Figma to React". Tcules calls the discipline design engineering: keeping product intent alive as designs become running software, through coded prototypes, frontend systems and implementation QA. Its Design to Code page makes the same point as this guide: a generated component is not successful because it resembles a frame; it has to behave correctly with real content, state, devices and assistive technology.

If the same differences keep coming back and nobody agrees why, the Design-to-Code Audit traces selected product decisions from design evidence through components and into the running product, compares tokens, states, responsive behavior, keyboard access and test coverage, and reports where the divergence enters. Its outputs are a decision-path map, a divergence ledger, a checking plan and a joint working session with design and engineering. It differs from design QA, which compares an implementation with a reference and files corrections, by asking why the divergence recurs. For review of a build already under way, see Implementation QA.