A Figma to React handoff checklist for founders and designers: tokens, states, responsive rules, and component boundaries that survive real production code. I write this as someone who designs and ships the same products: Figma is not the product, production React is.
Short answer
A Figma to React handoff survives code when it documents tokens, states, breakpoints, and ownership, not just pretty frames. Engineers should receive a component map that matches how React will actually compose UI. Designers should receive a preview URL and a punch list, not a surprise screenshot dump at launch.
If your handoff is “here is the Figma, build it,” you are paying for reinterpretation twice.
Why most Figma handoffs die in the first sprint
The file looks complete. Production needs answers the canvas never asked:
- What happens when the table is empty, loading, or failing?
- Which spacing values are tokens vs one-off magic numbers?
- Is the “card” a route, a button, or a layout wrapper?
- Does mobile keep the same information hierarchy or a different IA?
- Which motion is brand, and which is noise that kills mobile FPS?
Studios that both design and build close those gaps in the file before code starts, because the same people will own the bugs later.
The production handoff checklist
1. Tokens before screens
Ship a small token sheet first: color roles (not 40 random swatches), type scale, space scale, radii, borders, and elevation. Name them for product meaning (surface-raised, text-muted), not for the hex. Mirror those names in CSS variables so React never hardcodes brand colors in twenty files.
2. States for every interactive component
Default is not enough. For buttons, inputs, rows, and modals, show default, hover, focus, active, disabled, loading, error, and empty where relevant. Accessibility starts here: focus rings are design, not an engineer afterthought.
3. Responsive rules written as rules
Do not leave “it should feel fine on mobile” in Slack. Specify what collapses, what becomes a drawer, what truncates, and what is allowed to scroll horizontally. One composition per viewport for marketing heroes; denser product tables need explicit density choices.
4. Component map that matches React
List primitives (Button, Input, Badge), composites (EmptyState, DataRow), and page templates. Mark what is shared vs page-local. This is the difference between a design system and a folder of frames.
What engineers should refuse to invent
If the file is silent, product decisions get made in JSX under deadline pressure. Call these out explicitly in handoff notes:
- Empty states copy and next action
- Error copy and recovery path
- Permission-denied UI for roles
- Destructive confirmation patterns
- Motion: duration, easing, and reduced-motion fallback
On client builds I treat missing empty states as incomplete design, same as a missing primary button.
A practical file structure that helps React
- Foundations: tokens, type, icons, grids
- Components: variants + states only, no buried marketing art
- Flows: connected screens for the core job
- Spec: a page with links, breakpoints, and out-of-scope
Keep exploration pages separate. Shipping files should be boring and searchable.
Handoff rituals that actually save money
Kickoff walkthrough (30-45 min): designer narrates the core user job, not every frame. Engineer asks state and edge-case questions live.
Token freeze: agree names before styling the first page. Renaming tokens mid-sprint is expensive.
Preview QA: annotate a staging URL in Figma comments or a shared punch list. Pixel perfection is less important than hierarchy, spacing rhythm, and state coverage.
Motion pass last: Framer Motion belongs after the layout is honest. Animate opacity and transform, respect prefers-reduced-motion, and keep mobile budgets tight.
When engineer-led UI is the right call
Not every MVP needs a 120-frame Figma. If you have one workflow, a clear brand direction, and a studio that ships design and code together, wireframes plus a token starter can reach production faster. Invest deep Figma when multiple people will implement UI, when brand is a sales asset, or when density and hierarchy are the product (admin SaaS, data tools).
That is how I run many fixed-scope builds: design enough to remove ambiguity, then let React and real data expose the next design problems.
Annotation patterns that survive code review
Figma comments are ephemeral. Prefer a Spec page that answers:
- Breakpoint table (mobile / tablet / desktop widths you actually support)
- Z-index and overlay rules for modals, drawers, toasts
- Form validation timing (on blur vs on submit) and error placement
- Icon sizes and stroke rules so SVG imports stay consistent
- Content max lengths for titles, badges, and table cells
Engineers should paste those rules into a short DESIGN.md or Storybook docs so the next hire does not reverse-engineer spacing from screenshots.
Common translation bugs (and how to prevent them)
- Shadow and blur as identity. Heavy elevation stacks look fine on a marketing frame and muddy a dense SaaS table. Prefer one elevation language.
- Absolute positioning from Figma. Rebuild with flow layout unless you are doing a deliberate art-directed hero.
- Ignoring truncated text. Design the ellipsis and tooltip behavior for real org names.
- Button as link confusion. Mark navigation vs actions in the component map so React uses
Linkvsbuttoncorrectly for accessibility. - Dark screenshots, light tokens. If you only deliver light mode, say so. Partial dark mode guesses create thrash.
A thirty-minute review against this list before sprint start is cheaper than a week of pixel ping-pong.
Handoff for marketing vs product surfaces
Marketing heroes want one composition, brand-first type, and restrained Framer Motion. Product shells want density tokens, table patterns, and empty states. Do not force both into the same “card everywhere” language. Share color and type families; split templates. When the marketing site is a Vite SPA with prerendered SEO HTML and the app is Next.js, keep a shared token package so the brand does not fork by accident.
Production QA scorecard (pass / fail)
Run this against staging before calling the handoff done. Fail any row and the sprint is not closed.
| Check | Pass looks like | Common fail |
|---|---|---|
| Tokens | CSS variables match Spec names | Hex pasted in JSX |
| States | Empty/loading/error on core list | Happy-path mock only |
| Focus | Visible rings on all controls | Outline removed “for look” |
| Breakpoints | Mobile rules match Spec table | Desktop squeezed |
| Motion | Reduced-motion path works | Parallax still runs |
| Ownership | Repo + Figma links in handoff doc | Slack-only knowledge |
Score weekly for the first month after launch. Drift shows up as one-off spacing and orphan components.
Failure modes that burn budget
- Frame completeness theater: 90% of screens drawn, 0% of states specified
- Redesign during styling PRs: no change request, silent scope growth
- Icon pack chaos: three libraries, inconsistent stroke, no size tokens
- Marketing chrome in product: large radii and soft cards inside dense tables
- No content length rules: real org names break the layout on day one
Call these out in the kickoff notes so neither side pretends surprise later.
How this maps to studio work
On zaneone.one/portfolio you will see marketing sites and SaaS UIs where Figma decisions were made with implementation cost in mind: Vite SPAs with strong static SEO HTML where that fit, Next.js when the product needed App Router and server boundaries, and Framer Motion used as hierarchy, not decoration spam. Explore services if you want design-and-build in one engagement.
Related reading: SaaS UI systems, landing page motion performance, and Vite SPA vs Next.js.
FAQ
What should a Figma to React handoff include?
Include a token sheet (color, type, space, radius, elevation), component variants with empty/loading/error/disabled states, responsive rules for mobile and desktop, interaction notes for hover/focus/motion, and a written out-of-scope list so engineers do not invent product behavior.
Should developers rebuild every Figma Auto Layout frame as React?
No. Rebuild the product model: shared primitives, composition, and routes. Auto Layout is a layout hint, not a component tree. Flatten decorative wrappers and keep one source of truth for buttons, inputs, and cards.
How do you keep design tokens synced after launch?
Name tokens once in Figma and mirror the same names in CSS variables or a theme object. Change values in one place per release. Avoid exporting one-off hex codes into JSX. Review token drift in design QA the same week as visual QA.
When is engineer-led UI better than a perfect Figma file?
For an MVP with one core workflow, a senior design-and-build studio can ship faster from wireframes plus a token starter. Perfect Figma pays off when you have multiple surfaces, a brand system, or a team that will grow past one engineer.
Next step
Audit your current Figma against tokens, states, breakpoints, and a React-shaped component map. Close gaps before the first styling PR. If you want a studio that designs and ships the same React surface, start from contact.
Want this built for your product? Start a project with Zane, or explore shipped work, services, and more guides.