Start with the idea, not the tool.
Every loop starts the same way: a single sentence on a notepad. No spec, no wireframes, no stack decisions — just the rough shape of an app idea and a hunch it's worth a quick prototype.
The temptation here is to jump straight into building. The reason this workflow has three steps before code is that each one clarifies what comes next. Skipping the upstream steps usually means paying for them downstream in rewrites.
Talk it through in Claude Chat.
Chat is where rough ideas get pulled apart and put back together. The goal of this step isn't a finished product — it's a brief sharp enough that the next tool in the chain (Design) can actually act on it.
The pattern is simple: describe the problem out loud, then ask Claude to play it back. That alone tends to surface two or three assumptions that haven't been spoken yet. From there it's a back-and-forth — who is this for, what's the one job it has to do, what does success look like in the prototype.
What to ask for
A short brief covering audience, the single primary action the prototype should drive, the tone of voice, and a rough content outline. Nothing about colors, layout, or stack — those are deliberately downstream decisions.
The point of the chat step isn't to write the answer — it's to find the question.
What the step produces
- a.A one-paragraph description of the audience and the job the prototype does for them.
- b.The single primary action — everything else sits in service of this.
- c.A content outline — sections, in order, with one line of intent each.
- d.A short tone-of-voice note — a few words on how the copy should feel.
That brief is the artefact that hands off to the design step. If it's vague, design improvises — and improvised design is hard to undo later.
Hand the brief to Claude Design.
Design is the first time the idea has a body. It stops being words and starts being a layout, a typeface, a colour, a rhythm. The brief from the previous step goes in almost verbatim, and the first pass comes back fast.
What Claude Design produces isn't a static screenshot — it's a working HTML mockup you can poke at. That changes the conversation. Instead of debating "should the headline be bigger?" in the abstract, you ask for it bigger and see.
How to drive it
Start broad — a few different visual directions side-by-side — and converge once one feels right. From there it's small, specific edits: tighten the hero, simplify the nav, swap out a pattern that isn't pulling its weight. Every round takes minutes.
Why this step is in the loop
Sending a brief straight into a code tool works — but the result tends to be generically nice, and the rest of the day disappears into tweaks that are hard to picture in the abstract. Designing first means that by the time code starts, the visual decisions are already made and visible.
Design isn't decoration here — it's the contract between the idea and the build.
Pass the design to Claude Code.
The handoff is where the earlier steps pay off. Point Claude Code at the design, name the stack, and let it scaffold the project. Because the design is already settled, code's job shrinks from "invent a prototype" to "build this specific thing" — which is what it's good at.
What the handoff looks like
A short prompt with the design attached, the framework choice, where the prototype should run, and any content that needs wiring in. Claude Code takes it from there — sets up the project structure, writes the components, and runs a local preview to click through.
Where to steer it
Code isn't fully autopilot. There are a handful of places worth stepping in — judgment calls that benefit from a human looking at them once. Component structure, accessibility, and a couple of copy tweaks that only make sense once the prototype is real.
- a.Component structure — a quick look to make sure it'll be nice to live in.
- b.Responsive behaviour — resize the window, fix the places it breaks.
- c.Copy in context — rewrite the lines that read fine in the brief but feel off on a real page.
- d.Run it — a local preview, or a single command to share a link.
Why the loop has four steps.
Three tools, three artefacts, one prototype. The interesting part isn't speed — speed is the obvious one. It's that the final result tends to be sharper for having gone through three deliberate handoffs instead of one long prompt.
- 01Each step has one job. Chat clarifies, Design decides what it looks like, Code builds it. Nothing does two jobs at once.
- 02The artefacts are the contract. A brief, a mockup, a codebase — each one concrete enough that the next step can act on it without guessing.
- 03The human stays in the loop. Every handoff is a natural review point. You're not approving 5,000 lines at the end — you're approving a brief, then a design, then a build.
- 04It's faster, but that's a side effect. "Fast" stops trading off with "considered". Both hold because the considering happens upstream where it's cheap.
The tools keep changing. The shape of the loop — idea, brief, design, build — doesn't seem to.