How to Turn a Figma Design Into React

Turning a Figma design into working React code is a translation exercise: auto-layout frames become flexbox or grid containers, components and variants become React components and props, and color/spacing/type styles become a shared design-token system instead of one-off values. The process goes fastest when the Figma file was actually structured for handoff — consistent naming, real auto-layout, and defined styles — rather than a loose collection of pixel-positioned shapes. Below is a practical, step-by-step path from a finished Figma file to a maintainable React component tree, plus where a pre-built option like our Figma theme collection can shortcut a large chunk of the work.

This guide assumes you already have a Figma file you like and want to ship it as real, interactive React code — not that you're starting from a blank canvas. If you're earlier in the process and haven't picked a design yet, it's worth deciding whether you're designing from scratch or adapting a proven storefront layout, because that choice changes how much of this guide you'll actually need to do by hand.

Before You Touch Code: Audit the Figma File

The single biggest predictor of how painful a Figma-to-React conversion will be is not your React skill — it's how the Figma file itself is built. Spend fifteen minutes auditing it before you write a component.

Check for real auto-layout, not manual positioning

Open a few frames and look at how elements are arranged. If rows and columns use Figma's auto-layout (visible as a blue "resizing" icon and padding/gap controls in the right panel), that maps almost directly onto CSS flexbox: direction, gap, padding, and alignment carry over as near-literal properties. If elements are just placed at fixed x/y coordinates with no auto-layout, you'll be guessing at intended spacing and behavior on every breakpoint, which turns a translation task into a redesign task.

Check for components and variants, not duplicated frames

Click on a repeated element — a product card, a button, a badge. If it's a Figma component instance with variant properties (size, state, color), you can map it directly to a React component with typed props. If instead every card on the page is a separately duplicated group of shapes with slightly different values, you'll need to manually identify the actual variation points before you can build a reusable component at all.

Check for named, shared styles

Look at the local styles panel for colors, text styles, and effects. A file with a defined palette ("Primary/600", "Text/Muted", "Heading/Large") gives you a ready-made list of design tokens. A file where every layer has its own one-off hex value and font size means you'll need to reverse-engineer a token system by eye, which is slower and more error-prone, and it's the step most likely to produce visual drift between design and build.

If the audit turns up manual positioning, duplicated frames, and one-off colors throughout, it's worth being honest with yourself: rebuilding the Figma file to use proper auto-layout and components first will save more time overall than trying to code around its disorganization.

Step 1: Extract Design Tokens First

Before building a single component, pull every color, font size, spacing value, and border radius out of Figma into a plain list — a spreadsheet or a markdown table is fine. This becomes the seed for your CSS variables or Tailwind theme config. Doing tokens first, rather than styling components one at a time, is what prevents a storefront from ending up with fourteen near-identical shades of blue because three different developers eyeballed the same color from three different frames.

• Color: record every fill and stroke color used, then collapse near-duplicates into a single named scale (e.g. brand-600, neutral-200) rather than keeping every raw hex.
• Typography: capture font family, size, weight, and line-height for each named text style — headings, body, captions, buttons.
• Spacing: note the gap and padding values auto-layout frames actually use; most well-built files converge on a small scale (4, 8, 12, 16, 24, 32) even if it isn't written down anywhere.
• Radius and shadow: corner radius and elevation/shadow values are easy to skip and are usually where a React rebuild looks subtly "off" from the design if ignored.

Step 2: Map the Component Tree Before Writing JSX

Open the page in Figma and, without writing any code yet, sketch the component hierarchy you intend to build: Page contains Header, ProductGrid, Footer; ProductGrid contains repeated ProductCard; ProductCard contains Image, Title, Price, AddToCartButton. This step matters more than it looks like it should, because it's where you decide component boundaries — and getting those wrong is the most common source of an unmaintainable React codebase built from a design file.

A useful rule of thumb: if a group of elements in Figma repeats more than once, or has an existing component/variant behind it, it should almost always become its own React component with props — not inline JSX duplicated across the page. Conversely, don't over-componentize one-off layout sections that never repeat; a single-use hero section can live directly in the page component without needing its own file.

Step 3: Translate Auto-Layout Into Flexbox or Grid

With tokens and component boundaries decided, start building outward from the smallest components. For each frame using auto-layout, the translation to CSS is close to mechanical:

• A horizontal auto-layout frame with a gap becomes `display: flex; flex-direction: row; gap: <value>`.
• A vertical auto-layout frame becomes `flex-direction: column` with the same gap logic.
• Padding on the auto-layout frame becomes padding on the corresponding container element — copy the four values directly rather than approximating one number.
• "Fill container" vs "Hug contents" sizing modes map to `flex-grow`/`width: 100%` versus `width: fit-content` (or simply no explicit width) respectively.
• A grid of repeated cards (like a product listing) is usually better expressed as CSS grid with `grid-template-columns` and a responsive `minmax()`/auto-fit pattern than as nested flex rows, even if Figma modeled it as wrapping auto-layout.

Resist the urge to pixel-match by eye at this stage. Use the actual numeric values from the Figma inspector panel (padding, gap, corner radius) rather than eyeballing a screenshot — small consistent rounding errors compound across a full page and are one of the most common reasons a shipped page looks "almost right but off" compared to the design.

Step 4: Build Components With Props That Mirror Figma Variants

If a button in Figma has variants for size (small/medium/large) and state (default/hover/disabled), your React component's prop types should mirror that shape directly:

• Give each variant axis its own prop rather than one combined enum — `size: 'sm' | 'md' | 'lg'` and `variant: 'primary' | 'secondary'` stay legible; a single `type: 'primary-lg' | 'secondary-sm'` string does not.
• Let styling libraries do the variant-to-class mapping (a `cva`/class-variance-authority style pattern, or a small lookup object) rather than long chains of conditional class strings inline in JSX.
• Keep interaction states (hover, focus, active, disabled) in CSS/pseudo-classes where possible instead of React state, since Figma's "hover" variant is almost always describing a CSS `:hover` state, not something that needs JavaScript to track.

Step 5: Handle Responsive Behavior Explicitly

Figma files typically show one or two fixed-width frames (desktop, maybe mobile) rather than a fluid range of viewport sizes, so responsive behavior is the part of the conversion that requires the most judgment rather than direct translation. Decide, frame by frame, what should happen between the breakpoints you were given: does the grid go from four columns to two, or to one? Does the header collapse into a hamburger menu, and at what width? Write these decisions down as you go — they're exactly the kind of detail that gets forgotten and re-litigated later if it isn't recorded near the component.

Step 6: Wire Up Real Data Last

Build and visually verify components against static or mock data first, then swap in real data from your commerce backend once the layout is confirmed. Doing it in this order isolates two very different classes of bugs — layout bugs (wrong spacing, wrong breakpoint behavior) and data bugs (a product missing an image, an empty price field) — instead of debugging both simultaneously when a component first renders with a live product feed.

When to Skip Most of This: Starting From a Storefront-Ready Figma File

Everything above describes translating an arbitrary Figma file into React from scratch, which is real work even on a clean, well-organized file — easily days for a full storefront, longer if the file needs cleanup first. If what you actually need is a working ecommerce storefront rather than a from-scratch translation exercise, it's worth considering a Figma file that was already built with this handoff in mind. Our Figma theme collection is built with genuine auto-layout, named components with real variants, and a defined color/type/spacing system specifically so that the mapping described above is short and mechanical rather than exploratory.

For an e-learning or course-based storefront, the Course Whiz Figma theme follows the same discipline — consistent component naming and auto-layout throughout — so the steps in this guide apply directly rather than needing an extra cleanup pass first. If you're building for eyewear or optical retail specifically, the Optics Figma theme is organized the same way, with product-card and option-picker components already broken into sensible variant props. And for general apparel or multi-category catalogs, the Wosa Figma theme or the broader multi-niche Figma bundle give you more layout variety to pull from if you're not settled on one exact category yet.

To be clear about the honest tradeoff: starting from a purpose-built Figma file doesn't eliminate the need to understand the mapping in this guide — you'll still be translating auto-layout to flexbox and variants to props. What it removes is the uncertainty and cleanup work of Step 0, the audit. A file built for handoff means every frame you open already has real auto-layout, real components, and real named styles, so the mechanical steps in this guide are the entire job rather than the easy half of it.

Common Mistakes to Avoid

• Copying pixel values from a screenshot instead of the Figma inspector. Screenshots compress and can be off by several pixels; the inspector panel gives exact numbers.
• Building one giant component per page instead of following the Figma component tree. This makes future design changes require touching a wall of unrelated JSX instead of a single reusable component.
• Skipping the token-extraction step and inlining raw hex/pixel values. This is the single biggest reason a shipped React page drifts visually from its Figma source over time, since nobody has one place to update a color or spacing value.
• Guessing at responsive behavior that Figma never specified, then never writing the decision down anywhere, so the next developer re-guesses differently and the breakpoint behavior becomes inconsistent across the site.

Frequently Asked Questions

Do I need a plugin to convert Figma to React automatically?

Automated Figma-to-code plugins can generate a rough starting point, but they typically produce non-semantic markup and inline styles that don't match a real component architecture. Most teams use them, if at all, as a quick visual reference rather than as production output — the manual mapping process in this guide produces code you can actually maintain.

How long does a full Figma-to-React conversion usually take?

It depends heavily on how the Figma file is organized, not just the number of pages. A well-structured file with real auto-layout and components can go noticeably faster than a similarly sized file built with manual positioning, since most of the conversion time on a messy file goes into reverse-engineering intent rather than writing CSS.

Should design tokens live in Tailwind config, CSS variables, or a JS theme object?

Any of the three can work well; the important part is having exactly one source of truth that every component reads from, rather than three. Tailwind's CSS-first theme configuration and plain CSS custom properties are both common, low-overhead choices for a storefront build.

Can I use a pre-built Figma theme and still customize it heavily?

Yes — a purpose-built Figma file like the ones in our Figma themes collection is meant as a real starting point, not a locked template. Because the components and tokens are already organized cleanly, customizing colors, layout, and content tends to be faster than customizing a messy from-scratch file, since you're editing a defined system instead of untangling one first.