This post builds on the project template I use for Claude Code builds.
Three design sprint sessions. Problem framing, concept selection, storyboards in Miro Boards. The usual next step is opening Figma and spending a week or two building mockups. This time I pointed Claude Code at the sprint notes and had a working prototype by the end of the day.
Not a wireframe. A functional React app with routing, state management, filters that work, and mock data that actually makes sense in the business context. I did this across four interconnected projects over two weeks.
The inputs aren’t clean and that’s fine
Design sprint notes are messy by nature. I had Gemini summaries of hour-long discussions where people disagreed. Miro board exports with sticky notes pointing in three directions. Competing viewpoints that were never fully resolved because the sprint moved on.
Across four projects, 28 pivots. A drawer-based interaction replaced with inline expandable rows. A cumulative chart switched to daily occurrence counts when I realised cumulative trends were masking real patterns. An entire alternative dashboard view built as a “what if” exploration in a single session, it became a deliverable.
When prototyping takes hours instead of weeks, pivots stop being expensive. You can try the alternative and decide, instead of debating it in a meeting room.
Prototypes with business logic
What came out of Claude Code wasn’t a visual mockup. Each prototype had working business logic and mock data generated from a single deterministic seed: 500 pages, 6,100 events, 5 simulated actors. Every KPI was mathematically derivable from the same source array. Change the seed and the whole prototype recalculates.
This matters because the prototype behaves like a real product. Filters narrow the data. Pagination works. Charts respond to the actual numbers, not hardcoded screenshots. When a stakeholder asks “what happens if there are 200 open tickets instead of 5?”, you change the data and show them. Right there.
The fourth project was a deliberate merge of two earlier ones. Instead of rebuilding, it used build-tool path aliases to import components directly from the sibling projects. Same design system tokens, same mock data structure. The merge took a fraction of the time because the earlier work was composable, not disposable.
The testing angle nobody talks about
User testing tells you whether someone can complete a task. Preference testing tells you which version looks better. But neither tells you whether the design survives real data. Does the dashboard still make sense when there are 47 critical issues instead of 3? Does the chart communicate anything useful with six months of daily data instead of the two-week sample in the mockup? Does the layout hold when every status badge is red?
With a functional prototype, you can answer those questions before development starts. Vary the mock data. Switch from cumulative to daily counts. Load 500 items into the table that was designed for 20. Turn off the filters and see what the unfiltered state looks like.
Last month I had a prototype where the KPI cards showed a clean story with the default data set. I doubled the number of actors in the seed and the cards started competing for space. The percentage values went from single digits to triple digits and the layout broke. I found that in ten minutes.
What still doesn’t work
Mock data generators produce internally consistent numbers up to a point. Beyond that, the relationships between data points start to drift. A KPI that should be the sum of three other values isn’t. You catch it, fix it, and it happens again two waves later. The deterministic seed helps, but data integrity still needs manual checking.
Claude over-delivers. Every project, I spent time cutting features it built without being asked. A notification system nobody requested. An export function that wasn’t in scope. You have to be more disciplined about saying no precisely because saying yes costs nothing.
It creates noise. The sprint notes contain ten ideas and three decisions. Claude might build towards all ten unless you actively filter. The project template helps, the wave plan defines what’s in scope, but you still spend real time redirecting.
And the biggest gap: even with the most aggressive audit agents, getting design-system-quality artefacts without Figma input is hard. The prototypes work for internal testing and for aligning teams around decisions.
The design sprints produced decisions. Claude Code turned those decisions into something I could stress-test with real data before anyone wrote production code. The storyboard from the sprint is the hypothesis. The prototype is the experiment.
