How to Turn a Figma Design Into React

React implementation should follow the product's reusable concepts, not mirror the Figma layer tree. Use design evidence to define component responsibilities while keeping data fetching, state, routing, and accessibility within the application's architecture.

Key Takeaways

• Inspect the application boundaries and data flow before creating components.
• Split components by responsibility rather than by visible Figma groups.
• Keep product state explicit and preserve semantic browser behavior.
• Test user outcomes across server, client, error, and recovery paths.

What should you inspect in the React application first?

Inspect the repository's routes, rendering model, components, tokens, data fetching, state conventions, tests, accessibility utilities, and build constraints before translating Figma. React's 2026 “Thinking in React” presents a 5-step method from component hierarchy to inverse data flow. Apply it inside the existing architecture rather than creating a parallel component system from screenshots.

Review the framework, server and client boundaries, routing, data fetching, state management, forms, component library, styling, internationalization, testing, and accessibility conventions. The new UI should fit this architecture unless a separate migration is approved. Avoid adding a new state or styling system merely to mirror a design file. The Figma-to-code guide develops this connected responsibility in a dedicated guide.

Map route ownership and data contracts before JSX. Identify server-provided product data, client interaction state, mutations, authentication, and third-party integrations. Keep unbuilt APIs and unresolved requirements explicit instead of hard-coding a demo that cannot survive connection to production.

What belongs in a React component responsibility map?

A responsibility map should name each component's semantic job, inputs, state owner, data source, failure modes, and composing parent, while keeping page-specific layout local. React's 2026 “Thinking in React” uses 5 steps to derive hierarchy and state. The map should explain those boundaries, not force a one-to-one conversion from Figma frames.

Translate repeated product concepts into candidate components: ProductMedia, Price, OptionSelector, QuantityControl, AddToCart, ProductCard, FilterGroup, CartItem, and Feedback. Write what each owns and what it receives. A Figma frame or nested group is not automatically a React boundary. The Dev Mode handoff guide shows how to communicate this decision and its acceptance evidence.

Use composition for regions that need flexible children, props for bounded choices, and separate components for different behavior. Keep business rules in domain services or hooks according to the codebase. A component API should prevent invalid states where practical instead of exposing every visual combination.

How do you choose server and client boundaries carefully?

Choose server and client boundaries from data access, interactivity, browser APIs, personalization, caching, and framework rules; visual complexity is not the deciding signal. React's 2026 “Render and Commit” explains 3 rendering steps: trigger, render, and commit. Keep work server-side when possible, and introduce client state only where interaction truly requires it.

For 5B-5, maintain static product content and server-renderable structure on the server where the framework and application support it, and isolate client code around interaction. Do not mark an entire page client-side simply because one selector or carousel needs state. Follow current framework guidance for hydration and data ownership. The design-to-development handoff guide shows how to communicate this decision and its acceptance evidence.

Ensure server and client render the same initial meaning to avoid confusing shifts. Mode preference, personalized content, and browser-only behavior need stable fallbacks. Profile actual bundles and route behavior after integration rather than assuming component modularity guarantees performance.

How do you map the component model?

Map repeated anatomy and behavior into existing primitives, domain components, and page composition, documenting mismatches instead of mirroring every frame. Figma's 2026 “Guide to components in Figma” distinguishes 2 roles, main components and instances. React boundaries may differ because code must also own semantics, data, errors, and lifecycle beyond that two-role design relationship.

Inventory repeated patterns and identify stable boundaries: product media, price, option selector, quantity control, card, filter group, cart item, and alert. Decide which differences become props, composition, or separate components. Avoid one mega-component matching an entire frame. The component variants guide carries this responsibility into reusable properties and valid states.

• Write responsibilities before JSX.
• Map states to explicit props.
• Reuse existing application primitives.

How should you model data and state explicitly?

Model server data, derived values, URL state, form state, transient interaction, and durable user choices separately; store only what cannot be computed reliably. React's 2026 “Sharing State Between Components” demonstrates 3 core moves—remove local state, pass common data from the parent, and lift control upward—useful for eliminating contradictory selections and totals.

Define typed shapes for product identity, money, variants, media, availability, and errors. Distinguish server state from temporary interface state and derived values. Avoid duplicating price or selection logic in several visual components, because inconsistent updates become likely. The variables and design-tokens guide connects these values to a governed semantic vocabulary.

Render loading, empty, partial, stale, success, and failure states with deliberate recovery. Preserve shopper input across safe retries and prevent duplicate mutations. Figma examples should map to these states, but code remains responsible for concurrency, network races, and authoritative results.

How should you implement semantic accessible components?

Implement native elements and document order first, then add ARIA only where semantics require it and test focus, names, status, keyboard operation, and zoom in the browser. WHATWG's 2026 “HTML Standard” defines 6 heading ranks, h1 through h6. Preserve their hierarchy independently of component nesting or responsive visual order.

Use native elements and established accessible primitives. Maintain headings, landmarks, labels, descriptions, focus order, visible focus, and keyboard behavior. Dialogs, menus, listboxes, carousels, and composite widgets require more than click handlers and ARIA copied from a sample. Use the editable PoloThemes Figma bundle to inspect these decisions in a complete editable product.

Ensure dynamic feedback is available without color and announced where appropriate. Respect reduced motion and text resizing. Test component behavior with a keyboard and assistive technology in the integrated route because a Storybook-like example may not reveal focus or landmark conflicts.

How do you translate tokens and responsive behavior?

Translate semantic tokens through the repository's styling pipeline and implement layout as content-driven constraints, not coordinates from breakpoint frames. W3C's 2023 “Understanding Success Criterion 1.4.10: Reflow” evaluates at 320 CSS pixels, equivalent to 400% zoom from 1,280 pixels. Test that condition plus intermediate widths, long content, and missing data.

Map semantic design roles to the application's tokens and styling approach. Implement fluid layout with flex, grid, container, and media rules based on content needs. Avoid inline raw values copied from inspection when a shared role exists.

Keep source order logical when layouts change. Test long localized strings, zoom, browser font differences, image errors, many variants, and narrow containers. React does not solve layout resilience; the CSS and content model still need intentional constraints.

Why should you separate presentation from product state?

Separate visual variants from inventory, pricing, selection, cart, authentication, and request state so a style change cannot invent product truth. Figma's 2026 “Guide to Dev Mode” exposes 4 asset formats—PNG, JPG, SVG, and PDF. None represents domain state; connect components to typed product data and explicit transitions rather than exported mock values.

Design files illustrate states but do not own business logic. Connect components to typed domain data, model loading and errors, and keep server/client boundaries consistent with the framework. Do not bury pricing, availability, or cart rules inside visual components.

• Define data contracts.
• Render empty and failure states.
• Keep state close to the behavior that owns it.

How should you review hydration and state continuity?

Review server output, hydration, client updates, navigation, refresh, interruption, and back-forward history with real data; initial and hydrated markup should not contradict. React's 2026 “Render and Commit” separates updates into 3 steps. Instrument and test each boundary so a successful first render does not hide lost selection, duplicate effects, or inaccessible focus changes.

For frameworks that render on the server and hydrate on the client, test whether the initial product, price, mode, cart, and personalized regions preserve meaning during startup. Avoid rendering a misleading default that changes after interaction becomes available. Confirm client boundaries do not reset selection or focus during navigation. These behaviors depend on the chosen framework and application architecture, so follow current official guidance and verify the real route. Figma can document the stable intended states but cannot model hydration timing.

How should you build tests around behavior?

Build tests around observable tasks, semantic output, state transitions, errors, and recovery, reserving visual snapshots for stable appearance contracts. W3C's 2023 “What's New in WCAG 2.2” lists 9 criteria added after WCAG 2.1. Map applicable additions to automated checks and human browser evidence instead of treating a passing component render as accessibility proof.

Use component tests for property and state combinations, integration tests for data and mutations, and end-to-end tasks for discovery, selection, cart, and recovery. Visual regression can protect stable presentation, but it should not replace semantic and functional assertions.

Test rejected requests, changed inventory, invalid options, duplicate action protection, and navigation. Add accessibility automation where established and retain manual keyboard and assistive checks. A passing snapshot of the default state says little about commerce reliability.

How should you review and maintain the result?

Review the running journey with realistic data, assistive inputs, performance evidence, analytics, and code ownership, then record deviations from Figma and why they were necessary. React's 2026 “Thinking in React” contains 5 steps, but maintenance continues after them: keep tokens, component contracts, tests, and design documentation aligned as product behavior changes.

Run a designer-developer review with realistic data and representative viewports. Record deviations from Figma and decide which source should change. Remove prototype code, unused generated styles, and duplicated components before calling the conversion complete.

Document non-obvious component contracts and connect them to the design system where useful. After release, review errors, performance, and support evidence. Feed repeated fixes into shared components so the next route begins from a stronger React and Figma foundation.

Validate beyond the happy path

Use component-level examples for property combinations, then test integrated navigation, focus, announcements, responsiveness, and network behavior. Visual snapshots can catch drift, while task tests prove the flow still works.

• Test long and localized content.
• Verify keyboard and screen-reader behavior.
• Profile bundles and images in the integrated route.

Prove the React boundary with one vertical slice

Implement a collection card that opens a product route, resolves variant data, and submits an add-to-cart action. Use typed fixtures for regular pricing, sale pricing, missing media, unavailable inventory, delayed data, and a rejected request. This exposes whether the Figma pattern became a composable React interface or a visual component carrying routing, pricing, and cart responsibilities that belong elsewhere.

Review the component tree and state ownership alongside the rendering. Shared presentation receives explicit props; server-fetched facts remain authoritative; transient interaction state lives at the narrowest useful boundary; and form semantics work before decoration. Exercise keyboard focus, accessible status updates, responsive composition, and loading transitions. Avoid a variant prop for every difference when composition expresses the model more clearly.

Retain scenarios as component and integrated route tests. Visual snapshots catch styling changes, while behavior assertions verify selection, submission, recovery, and navigation. Document intentional differences from Figma and link them to accessibility, framework, or domain constraints. Future React changes should preserve the shopper decision without reconstructing unstated design logic.

Implementation checklist

• Components represent product responsibilities.
• Data and business rules have clear owners.
• All major states render intentionally.
• Integrated behavior and accessibility are validated.

Conclusion

A good Figma-to-React translation yields components that are recognizable to designers and natural to the codebase. That alignment makes future changes easier on both sides.

Frequently asked questions

Should every Figma component become a React component?

No. Some Figma components exist for editing convenience, while some code components manage behavior invisible in design. Map concepts, then choose boundaries appropriate to each tool.

Can generated React code save time?

It can help with prototypes or scaffolding, but must be reviewed for architecture, semantics, accessibility, dependencies, responsiveness, and maintainability.