Skip to main content

Claude/ChatGPT Prompt to Convert Figma to Accessible React Component

Turn a Figma design into a pixel-accurate, accessible, responsive React + Tailwind component with TypeScript props and Storybook.

Fill in the placeholders

Edit the values, then copy your finished prompt.

Your Prompt
prompt.txt

                                

What this prompt does

This prompt converts a Figma design into a pixel-accurate, accessible, responsive component and returns working code, not pseudocode. It casts the AI as a senior frontend engineer. You provide the [framework], the [styling] approach, the [dark_mode_strategy], and a [figma_description]. It returns a component that is pixel-accurate at 1280px and responsive down to 320px, semantic HTML with real headings and landmarks, full keyboard navigation with focus rings, dark mode via your strategy using tokens, TypeScript-typed props with a discriminated union for variants, and a Storybook story covering default, loading, and error/empty states.

The deliverables force accessibility and semantics in from the first pass instead of bolting them on later, which is where rework usually lives. Demanding the three Storybook states matters because the empty and error states are the ones design forgets. Driving dark mode through tokens rather than hardcoded colors keeps theming consistent, and the discriminated union for variants makes invalid prop combinations a type error.

When to use it

  • Turning a Figma frame into a production component in your [framework]
  • Forcing semantic HTML and keyboard support in from the first pass
  • Implementing dark mode via a specific [dark_mode_strategy] with tokens
  • Generating typed props with a discriminated union for variants
  • Producing Storybook stories that include the forgotten empty and error states
  • Building responsive components that hold from 1280px down to 320px

Example output

You get a component file and a Storybook story file. The component uses real headings, buttons, and landmarks; supports full keyboard navigation with visible focus rings; implements dark mode through tokens rather than hardcoded colors; and exposes TypeScript-typed props with a discriminated union for variants. The story covers default, loading, and error/empty states. A single line notes any assumption the model made from the Figma description so you can correct misreads quickly.

Pro tips

  • Write [figma_description] in detail — spacing, hierarchy, and states — since the model fills gaps with assumptions it will list at the end
  • Set [framework] and [styling] to your exact versions (e.g. React 19, Tailwind CSS v4) so the code uses current APIs, not outdated patterns
  • Match [dark_mode_strategy] to your app's real approach (class-based vs media-query) so the tokens integrate cleanly
  • Always keep the three Storybook states; the empty and error states are the ones design forgot and the ones users hit
  • Read the assumptions line the model returns and correct any that misread the design before you commit the code
  • Verify keyboard navigation and focus rings yourself — generated ARIA is a strong start but still needs a manual pass
  • Lean on the discriminated union for variants so invalid prop combinations become a compile-time type error rather than a runtime surprise

Frequently Asked Questions

Does it return real code or just a description?
It returns working code — a component file and a Storybook story file — in your chosen `[framework]` and `[styling]`. The prompt explicitly forbids pseudocode, though you should still review and test the output rather than shipping it unread.
How accessible is the generated component?
It uses semantic HTML, full keyboard navigation, focus rings, and ARIA only where semantics fall short. That is a strong accessibility baseline, but generated ARIA still warrants a manual pass and real keyboard testing, since automated output cannot fully verify the interaction experience.
Why insist on loading and error Storybook states?
The empty and error states are the ones design usually forgets, yet they are the states users actually hit when things go wrong. Forcing them into the story from the start prevents the common rework of adding edge-case handling after the happy path ships.
What if my Figma description is vague?
The model fills gaps with assumptions and lists them in a single line at the end. A vague `[figma_description]` produces more guesses, so the more spacing, hierarchy, and state detail you provide, the closer the output matches your design and the fewer corrections you make.
Engr Mejba Ahmed

Need this built for real?

Engr Mejba Ahmed

AI Developer · Software Engineer

I'm Mejba — I design and ship production AI systems, automations, and full-stack apps. If you want this turned into a working solution for your team, let's talk.

More in Frontend Development Prompts

Engr Mejba Ahmed

Engr Mejba Ahmed

Claude Code Expert · Online

👋

Hey there!

Quick Actions

WhatsApp Instant reply

Chat on WhatsApp

+880 1723 741224 · Instant reply

Popular Questions

Engr Mejba Ahmed is connected
Engr Mejba Ahmed is typing...
Engr Mejba Ahmed avatar

✉ Want me to follow up? Drop your email

Engr Mejba Ahmed avatar

📞 Connect Directly

Choose how you'd like to reach me

WhatsApp

+880 1723 741224

Email

[email protected]

✓ Details sent! I'll get back to you shortly.

Powered by OpenAI

335+

Blog Posts

25

AI Courses

63

Projects

Services & Expertise

Pricing & Process

Learning & Resources

Connect & Support