AI Code Generation — Figma to Next.js components with Figma MCP and Claude Code

Created:
Updated:

Introduction

This is the first project where I clearly saw how fast component‑driven development can move when AI is wired directly into your design tools. With Claude Code connected to Figma via MCP, I was no longer “translating” designs by hand — I was guiding a Next.js component library into existence from real Figma frames.

The goal was simple: start from Figma designs and end up with reusable Next.js components, not a pile of hard‑coded HTML in route files or page components. Pages should stay as thin shells that compose those building blocks. The result is a component library that can later be wired into Sitecore XM Cloud, but this post stays focused on the Next.js + Figma MCP + Claude Code workflow itself.

Instead of generic “make me a page” prompts, the key was giving the agent:

That combination is what consistently produced high‑quality, reusable components.

If you want to see where this fits in the broader pipeline:

High‑Level Workflow

At a high level, the loop looks like this:

Designs in Figma

Figma MCP server

AI coding agent

Next.js repo

Local / Vercel web preview

The rest of this post is about turning that diagram into a concrete, repeatable workflow.

Starting Point: Figma and a Component Map

I started with:

Equally important was deciding what I did not want:

The guiding rule was: pages compose components; components implement design.

Prerequisites and Setup

Figma and MCP

To let Claude “see” the designs, I wired Figma MCP into my environment. You can find the official docs here:

Minimum setup:

For Claude Code, this is the command that actually worked for me, following the Figma docs:

claude mcp add --transport http figma-desktop http://127.0.0.1:3845/mcp

Once that is in place, Claude can call MCP tools to pull real design data — colors, spacing, typography, layout, and component structure — from specific frames or nodes.

Next.js FE baseline

On the Next.js side I used the App Router with TypeScript, following the official Next.js docs:

The exact scaffolding command is not critical for this post; what matters is:

I also pointed Claude at the repo so it could read and edit files directly.

For styling, I standardized on:

That combination keeps the global CSS surface small, encourages reuse through Tailwind utilities, and still lets each component own its finer‑grained styling in a dedicated SCSS module.

Shaping the Repo for Component‑First Development

Before touching Figma, I shaped the project so that “components, not pages” was baked into the structure:

Then I used Claude to enforce that structure with an explicit prompt.

You are a senior Next.js engineer.

Project context:
- Next.js 16 with the App Router and TypeScript.
- We are building a component library that will later be reused in Sitecore XM Cloud front ends.
- Styling uses Tailwind CSS plus SCSS modules co‑located with components.

Goals for this refactor:
- Create a folder structure that keeps all UI inside src/components/**.
- Keep route files in src/app/** as thin composition files only, with minimal markup.

Tasks:
- Create src/components/layout and src/components/content folders.
- Move any existing layout markup from src/app/**/page.tsx into new layout components
  (PageShell, PageHeader, Section, etc.) in src/components/layout.
- Update page.tsx files so they only import and compose components (no layout HTML beyond the bare minimum wrappers).

Constraints:
- Do NOT change routing behavior or data fetching.
- Never define new visual components directly in page.tsx files.
- Use Tailwind utility classes for layout/spacing/typography and co‑located *.module.scss files for component‑specific styling; avoid adding new global CSS.
- Follow patterns recommended in the official Next.js App Router docs.

The important part is the project context at the top and the constraints at the bottom. That framing keeps the model aligned with Next.js best practices and your architectural intent.

The Core Loop: Figma Node → Reusable Component

Once the repo shape was right, I worked in a tight loop for each Figma section:

via MCP

Figma frame / node

Claude Code

New / updated React component

Human review in diff

Each iteration focused on a single component, not an entire page.

Defining the Component and Pulling Design Data

First, I picked a specific Figma node (for example, the hero section on the home page) and gave Claude a prompt that sets context and guardrails:

You are a senior React / Next.js engineer.
You have access to the Figma MCP server and the Next.js repo for this project.

Design context:
- We are implementing the "Home / Hero" frame from Figma:
  https://figma.com/design/[your-design-link]?node-id=[node-id-here]
- Use MCP tools to read layout, spacing, color tokens, and typography from this node.

Implementation goals:
- Create a reusable React component ContactHero in src/components/content/ContactHero.tsx.
- Follow Next.js 16 and React best practices for presentational components.
- All content (headings, body, buttons, images) must be passed via typed props.
- No data fetching, routing, or XM Cloud specifics in this component.
 - Use Tailwind CSS for high‑level layout/spacing/typography and a co‑located SCSS module (ContactHero.module.scss) for component‑specific styles and states.

Constraints:
- Do NOT modify any files under src/app/**.
- Do NOT create any new Next.js page files for this task.
- Create or update a co‑located ContactHero.module.scss file instead of adding styles to globals.
- Avoid inline styles and avoid adding new global CSS; rely on Tailwind utilities plus the SCSS module.
- Keep the component tree shallow and readable; avoid unnecessary wrappers.

Output:
- The full ContactHero component implementation.
- A short usage example showing how a page.tsx file would import and use it as its main JSX (with minimal extra markup).

Because MCP is in the loop, Claude does not guess at “a blue button” or “medium spacing.” It can pull:

The first draft is usually 80–90% correct.

Tightening Structure, Naming, and Props

Next, I refine the component API so it fits the rest of the library:

Refine ContactHero in src/components/content/ContactHero.tsx.

Goals:
- Ensure the props API is clean and future-proof for reuse across multiple pages.
- Align naming with the rest of the component library.

Requirements:
- Define a ContactHeroProps interface with explicit fields (eyebrow, title, body, primaryCta, secondaryCta, illustration, etc.).
- Make it easy to map from CMS / XM Cloud fields later (flat, predictable props).
- Keep ContactHero purely presentational; no hooks, no side effects.

Constraints:
- Do not change imports or exports used by existing consumers.
- Keep the rendered markup aligned with the current Figma frame.

This is where I think about future XM Cloud integration, even though I am still just building a Next.js library.

Style and responsive passes

Then I run focused passes for visual fidelity and responsiveness, always pointing back to Figma and the official docs where it helps.

Improve styles and responsiveness of ContactHero in src/components/content/ContactHero.tsx.

Design requirements:
- Match typography, spacing, and button styles from the "Home / Hero" frame in Figma.
- Use the mobile and desktop breakpoints defined in the Figma design system.

Implementation requirements:
- Follow the responsive layout patterns recommended in the Next.js docs
  (server components where possible, media-query-based layout only in client components).
- On small screens: stack content in one column, image below text.
- On larger screens: two-column layout with consistent gutter and max-width.
- Ensure focus states and contrast meet basic accessibility guidelines.
 - Use Tailwind utilities where they map cleanly to the Figma design tokens, and move any remaining component-specific styling into ContactHero.module.scss.

Constraints:
- Do not change the props interface.
- Keep all changes scoped to ContactHero and ContactHero.module.scss; do not touch page.tsx files or global CSS.

If anything still feels off, I call it out directly:

Spacing between the hero heading and body text is still too tight compared
to the Figma frame. Increase the vertical spacing to match the Figma values
and keep it responsive.

Short, targeted prompts like this are where MCP really shines — Claude can look back at the exact frame, see the spacing, and adjust the code.

Extracting and Reusing Patterns Early

As soon as I saw the same pattern repeating (headers, grids, cards), I asked Claude to extract shared components and update existing code to use them:

We are reusing the same hero header pattern on several pages.

Refactor:
- Extract a reusable PageHeader component into src/components/layout/PageHeader.tsx.
- Props:
  - title: string
  - eyebrow?: string
  - description?: string
  - align?: "left" | "center"

Then:
- Update the existing home, services, and projects hero components to use PageHeader.
- Remove any duplicated heading / eyebrow / description markup from those components.

Important:
- Do not change public props for the page-level components.
- Keep routing and data fetching exactly as-is.

This is where the library starts to feel like a real design system instead of a pile of one‑off components.

What I Got Done in a Day

With this workflow, a focused day of work produced:

Most importantly, I was not hand‑copying spacing values or eyeballing typography. MCP pulled those details from Figma, and Claude handled the mechanical code edits. I spent my time on structure, naming, and behavior.

Prompt Patterns I tend to use

A few patterns made the biggest impact:

If you are already comfortable in React and Next.js, this style of collaboration with a coding agent feels natural after a couple of iterations.

Beyond This One Site

Although this project focused on “Figma → Next.js components” in isolation, the same approach generalizes:

The common thread is simple: let AI handle “read the design and write the first draft of the UI,” and keep your effort for architecture, integrations, and user experience.

What made this experience stand out was not just raw speed; it was how much time I gained back to think about the product instead of wrestling with CSS. Designs in Figma turned into real components quickly, and I could iterate with a sentence or two instead of another hour in DevTools.

If you are working with Next.js (and especially if you plan to surface these components in Sitecore XM Cloud later), wiring Figma MCP into your coding agent is one of the highest‑leverage changes you can make to your frontend workflow.

Additional Resources

Previous Post
AI Workflows — Content operations pipelines with LangGraph-style agents
Next Post
AI Workflows — Image generation and editing from Content Hub DAM