Figma to Next.js: Where the Handoff Breaks
A practical Figma-to-Next.js handoff guide: design tokens, component contracts, breakpoint debt, files worth rejecting, and a review loop that stops pixel chasing.
Title: Figma to Next.js: Where the Handoff Breaks
Learning how to convert figma to next js usually starts with the wrong question: “which plugin turns frames into components?” The real question is narrower and less exciting: what must already be true in the Figma file before a Next.js developer can own the work without guessing?
Most conversions don’t fail because a developer can’t inspect a frame. Figma Dev Mode can surface specs without much trouble. They fail because the file does not declare the mechanics: tokens, breakpoints, states, content extremes, and interactive rules. A converter can emit JSX. It cannot recover intent that was never annotated.
How to convert figma to next js: the five-step handoff
Takeaway: treat the handoff as a contract, not an export.
- Promote raw values to named tokens. Every color, spacing step, radius, and text style needs a stable name before coding starts.
- Annotate states and breakpoints in the design file. Hover, focus, empty, loading, error, long text, reduced motion.
- Map Figma components to owned Next.js components. One
Cardin code, not three similarRectangleframes scattered across pages. - Exercise the built UI with real content. Long strings, missing images, narrow viewports, keyboard-only use.
- Review the deployed Next.js app, not just the Figma overlay. Behavior is the deliverable now.
If you already have a live Next.js codebase and the Figma file is drifting away from it, treat the work as a [migration]( /services/migrations ), not a fresh generation. That changes what you accept, what you reject, and how you estimate the work.
Design tokens are the only naming contract that survives the handoff
A file full of Rectangle 47 and raw hex values has no contract. The Next.js developer will name things differently, and the audit trail will disappear by the second sprint.
Figma’s design-token workflow is the closest thing to a shared vocabulary: when a token changes in Figma, the same name should already exist in code. That only works if the names are semantic.
Use names by role, not by appearance:
Bad token name | Good token name | Why it matters |
|---|---|---|
| | Design can change the hex without renaming the role |
| | The code reads like the product, not the file |
| | Component styles stay portable across pages |
A clean token map in Next.js can look like this:
.section {
padding-block: var(--space-section);
padding-inline: var(--space-gutter);
background: var(--color-surface);
color: var(--color-ink);
}That small abstraction is the difference between a handoff that survives change and one that breaks the first time the brand shifts.
What must be annotated in Figma before a developer starts
The rule is simple: if it is not explicit, the developer will invent it. Different developers will invent different versions.
Annotate | Why | If missing |
|---|---|---|
Hover, focus, and pressed states | Next.js needs visual states and ARIA behavior | Inconsistent or inaccessible interactions |
Empty, loading, and error states | Real apps spend meaningful time outside the ideal state | Unstyled fallbacks or broken layouts |
Long-content behavior | CMS text will not match the mock | Components overflow at real content length |
Breakpoint behavior | The design has to work between desktop and mobile | Developer guesses |
Reduced-motion alternatives | Motion-heavy UI needs a safe path | Users get motion they cannot turn off |
Figma Dev Mode may expose spacing and color, but it will not annotate product behavior for you. That is still design labor.
Responsive breakpoint debt is created in Figma, paid in Next.js
The fastest way to create breakpoint debt is to draw desktop and mobile as separate pages, with separate components, and no shared rules.
When DesktopNav and MobileNav arrive as disconnected Figma components, the developer will likely build two disconnected Next.js components. Now you own two navigations, two sets of states, and two places for a link to fall out of sync.
The fix is to model responsive behavior as variants and props on one component:
<CaseStudyCard
title={title}
image={image}
discipline={discipline}
href={href}
/>The card can change layout at breakpoints, but it remains one component with one set of tokens and states.
Ask for one component, many states. Not three screens pretending to be three components.
Design files worth rejecting outright
The most expensive thing you can do is start coding a file that is not finished enough to code against.
Send a design file back when:
- Colors, spacing, or type exist as raw values instead of named tokens.
- Breakpoints are implied by page names rather than annotated.
- Component variants have no hover, focus, empty, loading, or error states.
- The file contains only ideal content with no long-text or missing-image treatment.
- Accessibility labels, keyboard order, and reduced-motion behavior are absent.
- Every screen lives in one giant page with no component inventory.
A beautiful hero section is not a system. Figma export plugins can generate React, HTML, and CSS, and AI exporters can skip some manual wire-up, but none of them can recover missing product rules. The file has to be ready before the code starts.
The review loop that stops pixel chasing
Pixel chasing happens when the only shared reference is a static screenshot. The conversation stays at “move this 4px” because there is nothing else to discuss.
The loop that actually finishes projects is: review the running app at real sizes, with real content, in a real browser.
On the Usman Riaz portfolio, the client’s work didn’t fit one shelf. A metro train, an earthquake communication device, and a campus hiking app looked like three different designers. The solution was process-led structure: the home page names three disciplines, then shows the six steps every project goes through. Each case study uses the same anatomy, so the method reads clearly whichever project a visitor opens first. That’s the same handoff discipline the review loop needs—review the method and behavior, not just one screenshot. See the [Usman Riaz build]( /work/usman-riaz ) for how that structure ships.
When the handoff needs an owner from Figma all the way to production, that is a [prototype-to-production]( /solutions/prototype-to-production ) problem, not just an export problem.
FAQ
Can I just export JSX from Figma?
No. Exporters can produce React, HTML, and CSS, but they do not reliably produce owned, stateful, accessible components. Code generation can be a starting point; it is not the final handoff.
What should a founder check before a Next.js team starts?
The file needs role-based design tokens, breakpoint notes, hover/focus/empty/loading/error states, long-content behavior, and accessibility annotations. Without those, the developer is guessing and should be charging for discovery.
How do we stop pixel-by-pixel review?
Review the running app at real sizes, with real content and keyboard interaction. When the reference artifact is a deployed page rather than an overlay, the conversation stops being “move this 4px” and starts being “does the component behave correctly.”
imagePrompt: A precision technical drawing of a UI component split down the middle—one side cleanly labeled with measurement marks and connector pins, the other side unraveling into loose wires and blank sockets where the labels should be.