How Figma Make Turns Prompts into Prototypes

1. What Figma Make actually is

Figma Make is a Claude-powered feature inside Figma that converts natural language descriptions into functional, interactive prototypes. Not static image exports. Not Figma’s built-in click-through prototype mode, where you draw invisible tap targets on a static design and connect them with transitions. Actual running code — HTML, React — that you can click through in a browser, where forms submit, animations play, and navigation works.

The distinction matters because it changes what the prototype can tell you. A static mockup tells you what something looks like. A Figma click-through prototype tells you what sequence of screens exists. A Figma Make prototype tells you how the thing actually behaves — and behavior is where design meets engineering reality. Does the dropdown close when you click outside it? Does the form validate before submission? Does the animation feel right at the speed that code actually runs, not at the speed a designer imagined while dragging a transition handle? These questions can only be answered with running code.

Figma Make sits at the boundary between design tool and development environment. Designers describe what they want in plain English — “make this button trigger a slide-out panel with the user’s account settings” — and Claude generates the code that makes it happen. The designer stays in Figma, thinks in design language, and gets development output without writing a line of code. The workflow is new, but the underlying capability is Claude’s ability to understand intent from natural language and express that intent in working software.

2. The design-to-development gap

The gap between a Figma mockup and a working product has existed since design tools existed. A designer creates a pixel-perfect vision of what the product should look like. A developer builds the real thing. Between those two events — the handoff — something almost always goes wrong.

Part of what goes wrong is communication. A mockup shows one state of a design, maybe a few states. It doesn’t show the transition between states. It doesn’t show what happens when the text is longer than expected, or when the API call fails, or when the user is on a 320px-wide phone screen. The developer has to make decisions about all of these cases without clear guidance, and the designer often doesn’t find out about those decisions until the design review, weeks into development.

Part of what goes wrong is timing. The handoff happens at a fixed moment — design is “done,” development begins. But design is not actually done at the handoff. Design keeps evolving as development surfaces edge cases. What the developer builds reflects the state of the design at handoff time, not the state of the design at the moment the product ships, which means the developer frequently has to absorb late-arriving design changes and fit them into an existing codebase. This is expensive and friction-producing.

Part of what goes wrong is the medium mismatch. A static design communicates appearance and layout well. It communicates interaction and state poorly. Animation timing, hover states, focus behavior, error states, loading states — these are the substance of a good interaction design, and none of them survive the translation from Figma mockup to developer spec without loss. The developer guesses. Sometimes they guess right.

Figma Make addresses the gap by collapsing the distance between the design artifact and the behavioral specification. A Figma Make prototype doesn’t require the developer to interpret the design — it runs. The interaction behaviors, the animation timings, the state transitions are all demonstrably correct or demonstrably wrong, and they can be fixed before a single line of production code is written.

3. How Claude interprets design intent

The interesting part of Figma Make is not that Claude generates code — it’s that Claude understands what the designer means, which is often more than what they literally say.

When a designer writes “make this button open a panel with the user’s settings,” they aren’t specifying a React component tree. They aren’t defining the animation curve for the panel sliding in, or the keyboard handler for Escape to dismiss, or the scroll behavior when the panel content overflows. They are describing an intent: the button should give the user access to their settings without navigating away from the current page. Claude knows the interaction pattern — it has seen slide-out panels in thousands of codebases — and generates code that implements the full pattern correctly, including the details the designer didn’t specify.

This is what distinguishes Claude-powered design tools from template-based code generators. A template generator produces a rigid output that matches the template. Claude generates an output that matches the intent. If the designer asks for “a button that feels premium,” Claude interprets that as high contrast, appropriate sizing, smooth hover states, and crisp focus styles — because those are what premium buttons actually are. The code it generates reflects a semantic understanding of the concept, not just the literal words.

The practical implication for designers is that prompting Figma Make is more like briefing a capable developer than like filling out a form. Describe the interaction and the goal. Mention constraints if you have them. The more context you give — “this should feel fast, it’s a primary action, users will click it frequently” — the better the output matches what you actually want.

4. The designer workflow with Figma Make

The workflow that Figma Make enables is meaningfully different from the traditional design-then-handoff cycle. It’s iterative in a way that the old cycle wasn’t, because the cost of iteration is much lower when you can describe a change in a sentence and see running code in seconds.

A typical Figma Make session starts with a mockup. The designer has already done the visual work — colors, typography, layout, component states. The mockup captures what things look like. What it doesn’t capture is what things do. This is where the natural language prompting begins.

The designer selects a component or frame and describes the interaction they want. “When the user clicks the notification bell, show a dropdown panel with the last five notifications. Each notification should be dismissible with an X button. Mark all as read with the link in the footer.” Claude generates the code. The designer previews it in the browser — not in Figma’s prototype mode, but as actual running HTML/React in a real browser tab.

From there, iteration is natural language. “The dropdown is too wide, constrain it to 320 pixels.” “Add a loading skeleton for the first 300 milliseconds.” “The mark-all-read should be a button, not a link.” Each change takes seconds. The designer can explore different interaction approaches — does the panel slide in from the right or fade in from the bell? — without committing to an implementation choice before they know how it feels.

When the prototype is stable and the interaction is right, it serves as the specification for the production implementation. Developers receive a running prototype that demonstrates exact intended behavior, along with the generated code as a reference. The questions that typically arise in the design review — “what happens when the notification list is empty?” “what’s the animation timing?” — are already answered in the prototype. Development can begin from a precise behavioral specification rather than from an interpretation of a static image.

5. What “functional prototype” means in practice

The word “functional” is important here, and it is worth being precise about what Figma Make produces versus what it doesn’t produce.

A Figma Make prototype is genuinely functional: it runs in a browser, responds to user input, maintains state across interactions, and demonstrates real behavior. A multi-step form that shows the next step after each field validates, that tracks which steps are complete, and that shows a summary on the final screen — all of that works. The form actually validates. The state actually updates. The summary actually reflects the form state. This is categorically different from a Figma click-through prototype where “clicking the next button” just loads a pre-specified next screen.

What a Figma Make prototype is not is production code. The generated code isn’t designed for maintainability, performance at scale, accessibility compliance, security, or integration with a real backend. It’s prototype code: fast to generate, easy to iterate on, sufficient to demonstrate behavior, not appropriate to ship. Treating prototype code as production code is a category error that leads to technical debt and maintenance problems.

The right mental model is that Figma Make prototypes occupy the space that was previously occupied by coded prototypes built in tools like Framer or hand-rolled in React — but without requiring the designer to know code. The fidelity is higher than a click-through prototype and lower than production. The purpose is behavioral specification and validation, not shipping.

6. Vibe coding in a design context

Figma Make is the design world’s entry point into a paradigm that has been transforming how developers work: describe what you want, and get working software. The developer version of this is sometimes called vibe coding — rapid, natural-language-driven software creation where the programmer’s skill is in describing intent precisely rather than in implementing it mechanically.

For designers, Figma Make lowers the threshold for participation in this paradigm significantly. A designer who has never written JavaScript can now generate working interactive prototypes by describing them in natural language. The barrier between “having an idea” and “seeing it run” has collapsed in a way that fundamentally changes what designers can do with their time.

This has downstream effects on the product development process. When designers can prototype behavior at the speed of thought, more ideas get tested. More edge cases get explored. The product that ships has been more thoroughly validated before development starts. The developer receives a richer specification with fewer ambiguities. The feedback loop between design and reality becomes much shorter.

The longer-term trajectory of this capability is toward blurring the boundary between design and development further. As Claude-powered tools become more capable, the prototype output will approach production quality. The specific division of labor between Figma Make (prototype) and Claude Code (production) may evolve. What’s stable is the underlying pattern: natural language as the interface between human intent and working software.

"Make a dropdown menu"

"Create a notification dropdown that opens when a bell icon is clicked.
Show the last 5 notifications. Each notification has a title, timestamp,
and an X button to dismiss it. Include a 'Mark all read' link at the bottom.
The panel should close when clicking outside it. Use clean, minimal styling —
white background, subtle border, 12px font. No external dependencies, just HTML and CSS."

import anthropic

client = anthropic.Anthropic()

def generate_prototype(description: str) -> str:
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=2000,
        system="""You are a UI prototyping assistant. Generate clean, self-contained HTML with inline CSS and vanilla JavaScript.
Output only the complete HTML file with no explanation. The code must:
- Work when pasted directly into a browser
- Use no external libraries or CDN links
- Include all styles inline or in a <style> block
- Be interactive and functional (not just visual)""",
        messages=[{
            "role": "user",
            "content": f"Create this UI component: {description}"
        }]
    )
    return response.content[0].text

component = generate_prototype("""
A notification dropdown attached to a bell icon in the top-right corner.
Clicking the bell opens/closes the panel. Show 3 sample notifications with
title, timestamp, and dismiss button. Mark all read link at the bottom.
Closes on outside click.
""")

with open("prototype.html", "w") as f:
    f.write(component)
print("Open prototype.html in your browser")

def iterate_prototype(existing_code: str, change_description: str) -> str:
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=2000,
        system="You are a UI prototyping assistant. Modify the provided HTML to implement the requested change. Output only the complete modified HTML file.",
        messages=[{
            "role": "user",
            "content": f"Current code:\n\n{existing_code}\n\nChange: {change_description}"
        }]
    )
    return response.content[0].text