Generate Playwright Tests From Figma Designs Using Claude (Workflow That Actually Works)

Most QA test plans start after the feature is built. The developer ships, QA sits down, reads the PR, writes tests. By the time tests run, the feature has been merged and the team has moved on. Bugs found at this stage cost more — both in cycle time and in awkward conversations with developers who already shipped.

Generating tests from the Figma design before the developer writes any code shifts that timeline left. The design is the spec. With Claude (or any vision-capable LLM), you can extract that spec into a test plan and even into Playwright skeleton tests. I've been running this workflow on three client projects since the start of the year. Here's the practical version, the parts that work, and the parts that still need a human.

Table of Contents

• Why this workflow works (and where it doesn't)
• Step 1: Export design context from Figma
• Step 2: Generate the test plan with Claude
• Step 3: Generate skeleton spec files
• Step 4: Review with the developer before they code
• Step 5: Wire up real selectors when the build lands
• The actual prompts I use
• FAQs

Why This Workflow Works (and Where It Doesn't)

Designs encode three things tests need to know:

• What interactive elements exist. Buttons, inputs, dropdowns, toggles — all visible in the design.
• What states exist. Empty state, loaded state, error state, success state. Most designs ship variant frames.
• What the user is trying to accomplish. The flow tells you the test scenarios.

Designs don't encode:

• API contracts. (You still need backend specs.)
• Validation rules. ("Email must be valid format" isn't usually in the Figma file.)
• Edge cases the designer didn't think of. (3DS authentication, network errors, race conditions.)

So the workflow gets you ~70% of the way to a complete test plan. Human review and developer collaboration fill the last 30%.

Step 1: Export Design Context From Figma

Two ways to get the design into Claude's context.

Option A: Screenshot the relevant frames

Simplest. Copy the Figma frames as PNG, paste into Claude. Visible content + state variants in one shot.

Works best when:

• You have 3–8 frames to review.
• The frames already capture the variants (loaded, error, empty).
• You're not building tooling, just doing a one-off.

Option B: Export Figma's underlying data via the API

Figma's REST API returns the design as a JSON tree of nodes — frames, components, text, fills, etc. More structured but more setup:

curl -H "X-Figma-Token: $FIGMA_TOKEN" \
  "https://api.figma.com/v1/files/$FILE_KEY/nodes?ids=$NODE_IDS" \
  > design.json

Now you have machine-readable data. Useful when:

• You're building automated tooling that runs on every Figma update.
• You need to extract specific element names, dimensions, or properties.
• The design has 20+ frames you can't reasonably screenshot.

For most QA work, screenshots are fine. Don't over-engineer.

Step 2: Generate the Test Plan With Claude

I paste the design screenshots and a structured prompt. Output: a Markdown test plan organized by user journey, with happy and error paths, plus explicit "need clarification" callouts.

Sample output (slightly trimmed) from a real checkout-page design:

## Test plan: /checkout (from Figma frames)

### Critical paths
1. Single-item checkout, valid card -> success page
2. Multi-item checkout with quantity changes -> tax recalculates correctly
3. Apply valid coupon -> total updates, success indicator
4. Apply invalid coupon -> inline error "This code is invalid"

### State variants visible in design
- Empty cart (frame 3) -> redirect message, link back to /products
- Loading state (frame 5) -> skeleton blocks visible
- Payment error (frame 7) -> inline error in payment section
- Network error (frame 9) -> full-page error with retry

### Need clarification from product/design
- What happens if user clicks "Pay" twice in quick succession? Frame doesn't show.
- Is shipping editable post-checkout? Frames show shipping block, no edit affordance.
- 3DS / two-factor authentication for cards: not shown in any frame.

### Negative paths to add (not in design)
- Browser back button after submit
- Cart modified in another tab during checkout
- Session timeout mid-checkout

That's gold for a 2-minute LLM call. The "need clarification" section is the most useful part — it's the questions you'd ask in a kickoff meeting, prepared in advance.

Step 3: Generate Skeleton Spec Files

Once the plan is reviewed, hand it back to Claude with a request: "Convert this plan into Playwright spec skeletons. Use placeholder selectors I'll fill in once the build lands. Match this existing test as a style reference: [paste 60 lines of an existing test file]."

Output:

// tests/checkout/single-item-success.spec.ts
import { test, expect } from '@playwright/test';

test('single-item checkout with valid card succeeds', async ({ page }) => {
  await page.goto('/checkout');

  // TODO: replace with actual selectors when build lands
  await page.getByRole('textbox', { name: 'Email' }).fill('test@example.com');
  await page.getByRole('textbox', { name: 'Card number' }).fill('4242424242424242');
  await page.getByRole('textbox', { name: 'Expiry' }).fill('12/30');
  await page.getByRole('textbox', { name: 'CVC' }).fill('123');

  await Promise.all([
    page.waitForResponse((r) => r.url().includes('/api/checkout/charge')),
    page.getByRole('button', { name: 'Pay' }).click(),
  ]);

  await expect(page).toHaveURL(/\/thank-you/);
  await expect(page.getByRole('heading', { name: /thank you/i })).toBeVisible();
});

Skeleton has structure (correct flow, web-first assertions, network waits) but no real selectors. Easy to fill in when the build lands.

Step 4: Review With the Developer Before They Code

This is the step that converts "AI saved me time" into "AI saved the team time."

Send the test plan to the developer who's about to build the feature. "Here's what I plan to test. Anything missing? Anything that conflicts with how you're planning to build it?"

Almost always two things come back:

1. The developer corrects something the design didn't make obvious. "Actually we're not adding the coupon UI in v1; that ships next sprint."
2. The developer thinks of an edge case neither you nor the design covered. "Oh, we need to handle the race where the user navigates away mid-payment."

Both are valuable. Both happen earlier than they would have otherwise.

Step 5: Wire Up Real Selectors When the Build Lands

Once the developer ships a PR, the skeleton tests get real selectors. With proper data-testid coordination (you put the names in the test plan; the developer adds matching attributes), this is mechanical.

If you're using the Playwright 1.59 generator agent (see my agents post), you can hand the skeleton + the deployed page to the agent and it fills in the selectors. Manual is fine too; the skeleton is most of the work.

The Actual Prompts I Use

Prompt 1: Test plan from design

I'll send you Figma frames for a feature. For each frame, identify:

1. The user journey (what is the user trying to accomplish?)
2. Interactive elements visible (buttons, inputs, dropdowns)
3. Visible state variants (loading, error, empty, success)

Then output a test plan in Markdown with: critical paths, state variants, items needing clarification, and negative paths likely missing from the design.

Be specific. Don't write generic test names. Use exact button labels from the design.

[paste images]

Prompt 2: Skeletons from plan

Convert this test plan into Playwright spec skeletons. Use TypeScript. Match this existing test as the style template — same fixtures, same assertion patterns, same selector approach (role-based with TODO comments where I need real selectors after the build).

Each skeleton should be a separate file. Don't bundle multiple tests into one file unless they share setup that's costly to repeat.

Plan: [paste plan]

Existing test for style reference: [paste existing test]

Prompt 3: Update tests when design changes

The design changed. Here are the old frames and the new frames. List the test changes I'll need to make: tests to add, tests to delete, tests to modify (and how).

Old: [images]
New: [images]

FAQs

Doesn't this just produce generic tests?

It produces structured starting points. The plan is generic by design — your review tightens it to your team's standards. The output is way better than starting from a blank page.

What if the developer changes the design during build?

Re-run prompt 3 with the updated frames. Update the plan and skeletons. Total time: 5 minutes.

Does this work with Sketch or other design tools?

Yes — same workflow with screenshots. Sketch and Adobe XD have similar export capabilities. Linear/Notion mockups work too.

Can I run this entirely automated on every Figma update?

Possible but expensive. Each plan generation burns tokens. I run manually when a new feature is starting; automation makes sense for teams shipping multiple features per week.

What if the design is in a Figma plugin or non-standard format?

Screenshots are the universal solvent. Whatever rendering tool you use, screenshot the result and feed it to Claude.

Does Claude do better than ChatGPT or Gemini at this?

Claude Sonnet 4.6 produces the cleanest test plans in my experience. GPT-5 is close. Gemini's vision is improving but historically less reliable for structured output.

What about the new Figma → code AI tools?

Different category — they generate UI code. The QA test-plan workflow is a different output. Both can run in parallel.

How does this fit with BDD?

You can have Claude output Gherkin instead of test code. Same workflow, different format. Useful if your team uses Cucumber.

Is this overkill for a 2-test feature?

Yes. For tiny features just write the tests. The workflow shines on features with 5+ states or complex flows.

What about testing accessibility from designs?

Claude can flag obvious issues (missing labels, low contrast guesses). For real a11y testing you still need axe-core against the actual implementation.

Wrap-Up

Generating tests from designs isn't magic, but it's also not science fiction. The workflow shifts test planning left in the development cycle, surfaces clarifications before the developer writes code, and produces skeletons that are 70% of the way to working tests. For features with multiple states and flows, it pays back the setup time many times over.

If your team wants help adopting AI-assisted test planning workflows, that's part of framework engagements. Or book a free call.

Related reading:

• Playwright 1.59 Agents Explained
• AI-Generated Tests Producing Garbage
• AI in QA Automation 2026
• Using Claude Code for QA