Real World Workflow Design To Code With Figma MCP

Knowing how to configure Figma MCP is one thing. Applying it effectively in a real sprint — with a live design system, existing codebase conventions, deadlines, and designer/developer handoff friction — is another. This topic presents the complete, end-to-end workflow a senior developer would run when implementing a new UI component from a Figma design using an AI agent and Figma MCP.

The workflow is tool-agnostic: the prompts and steps work in Claude Code, Cursor Agent mode, OpenCode, or Gemini CLI with only minor prompt adjustments. Use what fits your environment.

Workflow Overview: From Figma Frame to Production-Ready UI Component

The workflow has four stages:

1. Extract — Pull design context, screenshots, and variables from Figma. Orient the agent on what it's working with before a single line of code is written.
2. Map — Align Figma design tokens to codebase CSS variables, and Figma component instances to existing React components. Identify gaps.
3. Generate — Write the component, CSS module, Storybook stories, and unit tests using the agent with the full context established in steps 1 and 2.
4. Refine and commit — Run the linter, type checker, and visual comparison. Apply corrections in targeted follow-up prompts. Commit with a structured message.

This staged approach prevents the most common failure mode: asking the agent to jump straight to code generation before it has enough context, producing output that mixes real design tokens with invented values and generic HTML instead of design system components.

Prerequisites for this workflow
- Figma MCP configured in your agent of choice
- Figma file ID and target frame node ID (from designer handoff or Figma link)
- Access to the codebase: token file, component directory, Storybook setup, test setup
- A clear component name and destination path agreed on with the team

Tips
- Agree on the component name and file path with your team before starting the session — renaming after generation causes cascading import changes that waste iteration cycles.
- Keep a DESIGN.md at the project root documenting the Figma file ID, design system file ID, and a table of key frame node IDs for components in progress — the agent can read this as a session bootstrap.
- Run the full four-stage workflow for any net-new component. For modifications to existing components, skip stage 1 orientation and go straight to a diff-focused prompt.
- Time-box each stage: orientation ~5 minutes, token mapping ~10 minutes, generation ~20 minutes, refinement ~15 minutes. If a stage is taking longer, something is ambiguous — stop and clarify rather than iterating blindly.

Step 1: Extracting Design Context and Identifying Reusable Components

This is the foundation of everything that follows. A thorough orientation step prevents misinterpretation and produces a checklist you can verify against at the end.

Context for this example
- Component to build: PricingCard — a card displaying a subscription plan with a plan name, price, feature list, and a CTA button
- Figma file ID: SAAS_DS_2025
- Frame node IDs: 88:400 (Starter tier), 88:401 (Pro tier), 88:402 (Enterprise tier) — three variants of the same component

Prompt 1: Extract design context for all three variants

Using Figma MCP:
1. Call get_design_context for node-ids 88:400, 88:401, and 88:402 in file SAAS_DS_2025
2. Call get_screenshot for node-id 88:401 (the Pro tier — it is the most visually complete)

From the design context, produce a structured analysis:

Layout:
- Root element layout (flex direction, padding, gap, min/max width)
- Section breakdown: header area, price area, feature list area, CTA area

Differences between variants (88:400 vs 88:401 vs 88:402):
- What changes between tiers? (colors, button labels, feature count, badge visibility)
- What stays the same? (layout, typography scale, spacing)

Component instances found:
- List each Figma component instance name and the node it appears in
- For each, state whether we should use an existing React component or generate new markup

Typography:
- All text styles used (font, size, weight, line height)
- Which text styles appear to be from a shared library (named styles) vs. local overrides?

Colors:
- All unique fill colors (hex values)
- Background fills on the card container per variant

Do not write any code. This is an analysis step only.

Prompt 2: Map component instances to codebase components

From the analysis above, the component instances identified in the PricingCard frame include:
- "Button/Primary" (the CTA)
- "Badge/Popular" (the highlighted badge on the Pro tier)
- "Icon/Check" (the feature list checkmarks)

Check the following files and confirm the correct import paths and prop APIs:
- src/components/Button/Button.tsx (or index.ts)
- src/components/Badge/Badge.tsx
- src/components/Icon/Icon.tsx

For each, list:
- Named export
- Relevant props for this use case (variant, size, children, etc.)
- Any prop the Figma design implies that the component does not support (flag as a gap)

Prompt 3: Identify gaps

Based on the component inventory:
1. Are there any elements in the PricingCard design that do not have a corresponding component in src/components/ and would need to be implemented as raw HTML/CSS?
2. Is there a FeatureList or similar component we should create as a sub-component of PricingCard?
3. Does the design show any states (hover, focus, loading) that need to be handled but aren't visible in the static frame?

List the gaps and a recommendation for each (reuse existing, create sub-component, or handle inline).

Tips
- Always extract multiple variant frames simultaneously when a component has variants — it lets the agent understand the full prop surface before writing TypeScript types.
- The "differences vs. similarities" analysis directly maps to your TypeScript prop interface: similarities are hardcoded layout, differences become props.
- When the agent identifies component instances in the design context, cross-reference against your actual component directory immediately — hallucinated component names are a common source of import errors.
- Document the gap analysis output before writing code — gaps that become "implement inline" decisions should be reviewed by the team, as they may indicate missing design system components that should be built first.

Step 2: Mapping Figma Tokens to Code Design System Variables

With the structural analysis complete, the next step is establishing a reliable mapping between the colors and spacing values in the Figma design and the CSS custom properties in your codebase. This step prevents hardcoded hex values from leaking into the component.

Prompt 4: Extract Figma variables

Call get_variable_defs for Figma file SAAS_DS_2025.
List all variable collections and the variables within each. For the "Colors" collection, show both Light and Dark mode values if they exist.

Prompt 5: Reconcile Figma tokens with codebase tokens

Read the file src/styles/tokens.css.

Now compare the colors extracted from the PricingCard design context (step 1) against both:
1. The Figma Variables from SAAS_DS_2025
2. The CSS custom properties in tokens.css

Produce a mapping table with columns:
| Figma Variable Name | Figma Value (hex) | Matching CSS Token | CSS Token Value | Match? |

Mark rows:
- "exact" if the hex values match exactly
- "close" if they're within 5% perceptual difference (note the discrepancy)
- "no match" if no CSS token exists for this value

For "no match" rows, suggest a token name following the existing naming convention in tokens.css.

Expected output format from the agent:

Prompt 6: Handle missing tokens

For tokens marked "no match" in the mapping table:
1. Add them to src/styles/tokens.css in the appropriate section, following the existing naming convention.
2. Show the exact lines to be added.
3. If the missing value is a dark mode variant, add it to both the :root block and the @media (prefers-color-scheme: dark) block.

Prompt 7: Spacing and radius token mapping

From the PricingCard design context, extract:
- All padding values (inner spacing of the card container, section gaps)
- All border-radius values
- Any explicit gap/margin values

Map each to the closest token in src/styles/tokens.css (look for --spacing-* and --radius-* tokens). 
If the exact value doesn't exist as a token but is a multiple of the base unit (4px), note that and use calc() if needed. 
Output as a mapping table with the same format as the color mapping above.

Tips
- Run this token mapping step before any code generation — fixing token mismatches in CSS after a component is generated is error-prone and time-consuming.
- Keep the mapping table output in a comment block at the top of the component's CSS module for future reference: "/ Token mapping: Figma card-highlighted → --color-brand-50 /".
- If you find many "no match" tokens, pause and discuss with the design team before adding them — it may indicate that the design diverged from the design system and needs correction in Figma rather than accommodation in code.
- "Close" matches (perceptually similar but not identical values) are usually bugs in the Figma file — the designer used a hardcoded color instead of a variable. Flag these and ask the designer to fix them before implementation.

Step 3: Generating, Refining, and Committing Component Code with AI

With orientation complete and tokens mapped, code generation is the most straightforward step — but it still requires structured prompting and a disciplined review process.

Prompt 8: Generate the component

Generate the PricingCard React component based on:
1. The design context from node-ids 88:400, 88:401, 88:402 in file SAAS_DS_2025 (established in step 1)
2. The token mapping from step 2 (use CSS custom properties from src/styles/tokens.css, never hardcode hex values)
3. The component API: Button from src/components/Button/, Badge from src/components/Badge/, Icon from src/components/Icon/

Component requirements:
- File: src/components/PricingCard/PricingCard.tsx
- CSS Module: src/components/PricingCard/PricingCard.module.css
- Barrel export: src/components/PricingCard/index.ts
- TypeScript interface PricingCardProps:
  - planName: string
  - price: string (e.g., "$29")
  - billingPeriod: string (e.g., "/month")
  - features: string[]
  - ctaLabel: string
  - onCtaClick: () => void
  - isPopular?: boolean (controls badge visibility and highlighted card style)
  - variant: 'starter' | 'pro' | 'enterprise'
- Accessibility: role="article", aria-label="{planName} plan"
- Feature list should use a <ul> with <li> items, each with a visible checkmark icon using Icon component

Generate all three files now.

Prompt 9: Validate generated output

Run the following checks on the generated PricingCard component:

1. TypeScript: Run tsc --noEmit in the project root. If there are errors in src/components/PricingCard/, show them and fix them.
2. Import verification: Confirm that all imported components (Button, Badge, Icon) exist at the imported paths. Check the actual files in src/components/.
3. CSS token verification: Confirm that every color value in PricingCard.module.css uses a CSS custom property from src/styles/tokens.css (no hardcoded hex values).
4. Screenshot comparison: Call get_screenshot for node-id=88:401 (Pro tier). Compare visually against the generated CSS. List discrepancies in layout, spacing, or visual treatment.

Prompt 10: Generate Storybook stories

Generate a Storybook 7 CSF3 story file at src/components/PricingCard/PricingCard.stories.tsx.

Include:
- Starter: variant="starter", isPopular=false
- Pro: variant="pro", isPopular=true (this should show the badge and highlighted style)
- Enterprise: variant="enterprise", isPopular=false
- AllVariants: a story showing all three side-by-side in a flex row (use a layout decorator)

Controls: all string props (planName, price, billingPeriod, ctaLabel), isPopular boolean toggle
Actions: onCtaClick

Use a decorator to constrain each story to 320px min-width to match the Figma frame width.

Prompt 11: Generate unit tests

Generate a Vitest + React Testing Library test file at src/components/PricingCard/PricingCard.test.tsx.

Test cases:
1. Renders plan name, price, billing period
2. Renders all features from the features prop
3. Renders the "Popular" badge when isPopular=true, hides it when false
4. Calls onCtaClick when the CTA button is clicked
5. Has correct aria-label containing the planName
6. Snapshot test for the Pro variant (isPopular=true)

Use getByRole and getByText queries — avoid getByTestId.

Prompt 12: Final review and commit preparation

Summarize the PricingCard implementation:
1. List the files created and their purposes
2. Confirm all tokens used (cross-reference tokens.css)
3. List any design gaps or decisions made during implementation that the design team should be aware of
4. Suggest a git commit message following conventional commits format

Then run:
- tsc --noEmit
- eslint src/components/PricingCard/
Report any remaining errors.

Committing the work

Once the prompts complete cleanly:

git add src/components/PricingCard/ src/styles/tokens.css

git diff --staged

git commit -m "feat(pricing-card): implement PricingCard component from Figma design

- Adds PricingCard with starter/pro/enterprise variants
- Maps Figma SAAS_DS_2025 design tokens to CSS custom properties
- Uses existing Button, Badge, Icon components
- Adds Storybook stories and Vitest unit tests
- Adds missing --color-brand-50 token to tokens.css

Figma frame: SAAS_DS_2025, nodes 88:400–88:402"

Tips
- Generate the component, stories, and tests in separate prompts rather than one mega-prompt. Each artifact benefits from the model's full attention, and it is easier to re-run one step if it produces poor output.
- After tsc --noEmit passes and the linter is clean, do a manual review focused on accessibility and responsive behavior — these two areas are where AI output most consistently needs human adjustment.
- Include the Figma file ID and node IDs in the commit message body — this creates a permanent link between the code and the design at the point of implementation, invaluable for future redesign work.
- Run your Storybook locally and visually compare each story against the Figma frame before merging. This takes 5 minutes and catches issues that automated checks miss. Use Figma's side-by-side view if your team has Figma on a second monitor.