# Turn a mockup into a working prototype

Attach a mockup image in Claude Code and get a clickable prototype that follows its layout and states, built in its own folder with fake data.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Here is a mockup: the image attached to this message. Build a working prototype I can click through, matching the layout and states shown.

What it is for: {{purpose}}
{{#states}}
States and interactions to include:
{{states}}
{{/states}}
Build it as {{stack}}.

Before building, list what you see in the mockup: screens, components, text and the states it implies. If no image is attached, or part of it is unreadable, stop and tell me.

Rules:
- Put all new files in one new folder{{#folder}}: {{folder}}{{/folder}}. Do not change or delete existing files.
- This is a prototype: use fake data, no backend, no real requests and no new dependencies.
- Before building, list interactions the mockup does not specify, such as where a button leads or what an error looks like. Ask me about the ones that matter for the flow. Build the rest as clearly marked placeholders; do not invent their behavior.

When it is built, if you have a browser tool (the Desktop preview, the Chrome extension or a Playwright MCP server), click through the path to each state and compare the rendered page with the mockup. If not, say it was not verified and list the checks I should do by hand.

Tell me how to open it. Finish with:
1. The files you created.
2. A click path that reaches each state.
3. Where the prototype differs from the mockup, and why.
4. Placeholders, open questions, and what you verified in the browser.
```

## Fields

- `{{purpose}}` (required): What the screen or flow is for. One sentence. Attach the mockup image in Claude Code itself; this page cannot hold images.
- `{{states}}`: States and interactions to include. Optional. Especially the states the mockup does not show.
- `{{stack}}`: How to build it. Choose one:
  - a standalone page in HTML, CSS and vanilla JavaScript, with no build step (default)
  - part of this project, using the framework and components it already has
- `{{folder}}`: Folder for the prototype. Optional. Claude puts every new file here.

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- You have a static mockup and want something people can click through, so questions about flow and interaction come up before engineering work starts. Paste, drag or @-mention the image into Claude Code before you send the prompt.
- You want to hand engineering a working example of the interactions instead of describing them in a document.
- You want to try two or three variations of a screen quickly and compare them in a browser rather than in a design tool.

## When not to use it

- You need production code that matches the design exactly. Use the screenshot template, which builds into the real app and checks the result against the image.
- You have no mockup yet, only an idea. Describe the tool in words instead, or pin down the requirements with a spec interview first.
- You cannot attach images where you run Claude. This page cannot carry an image, and without it Claude would be guessing the layout.

## Why this structure

- The opening line refers to the attached image, and the prompt asks Claude to stop if none is attached. A prototype built without the mockup would look plausible and match nothing.
- Listing what Claude sees before it builds makes its reading of the mockup visible. You can correct a misread label or a missing screen before it is built in.
- The states field covers what a single static image rarely shows, such as errors, loading and success, which is where a clickable prototype adds the most.
- The rules keep the work contained: one new folder, no edits to existing files, fake data and no requests. You can delete the folder and nothing else in the project has changed.
- The build setting decides whether the prototype stands alone or uses the project's own components. A standalone page is quick to share; project components make the prototype closer to what will ship.
- Unspecified interactions are flagged before building, and the ones you do not answer become marked placeholders. You see which behavior came from the mockup and which is still undecided, instead of finding invented behavior later.
- The click-through step gives Claude a check when a browser tool is available, and asks for a list of manual checks when it is not, so the report says plainly whether the prototype was looked at.
- The closing list asks for a click path to every state, each difference from the mockup and the remaining placeholders, so you can review the result in a few minutes.

## Example input (fictional)

What the screen or flow is for:

```
A three-step signup flow for a team plan
```

States and interactions to include:

```
Empty form, an invalid email error, a loading state after submit, and a success screen with a link to invite teammates.
```

How to build it:

```
a standalone page in HTML, CSS and vanilla JavaScript, with no build step
```

Folder for the prototype:

```
prototypes/team-signup/
```

## Follow-ups to send Claude

- Add a second version of step two with the plan options as cards instead of a list, and a toggle to switch between them.
- Make the prototype work at phone width and tell me which parts of the mockup did not fit.
- Write a short handoff note for engineering: each state, what triggers it, and the assumptions that still need a decision.

## Common mistakes

- Sending the prompt before the image is attached in Claude Code. Check that the image appears in the message first.
- Expecting the mockup alone to define behavior. Name the states and interactions you care about; otherwise Claude has to ask about each one or leave it as a placeholder.
- Letting the prototype grow into the product. Keep it in its folder with fake data; when the design settles, build the real feature against the codebase.

## Related templates

- [Implement from a screenshot and self-check](https://awesomeclaudeprompts.com/prompts/implement-from-screenshot/): Give Claude Code a design image; it builds the UI, screenshots the result, compares the two and fixes differences for a set number of rounds.
- [Map edge cases before building](https://awesomeclaudeprompts.com/prompts/map-edge-cases/): Ask Claude Code to list the error states, empty states and edge cases a feature must handle, so the design covers them before anyone builds it.
- [Write a spec by interview](https://awesomeclaudeprompts.com/prompts/spec-by-interview/): Let Claude Code interview you about a feature, covering implementation, UX, edge cases and tradeoffs, then write a self-contained spec to a file.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code docs: Common workflows, work with images](https://code.claude.com/docs/en/common-workflows#work-with-images) (Anthropic documentation)
- [How Anthropic teams use Claude Code](https://claude.com/blog/how-anthropic-teams-use-claude-code) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.