Prototyping with Claude Design

We recently jumped on the Claude bandwagon at Climate Policy Radar and got a company subscription. As luck would have it, that coincided with the launch of Claude Design. It has been a fun few months!

In this post, I share how I am quickly building interactive low-fidelity prototypes with Claude Design to test ideas and get feedback faster. I also give some examples of how this has helped me to do better product work.

How I use Claude Design

I usually follow the same 4-step workflow when prototyping with Claude:

Step 1: The Brief

I never open Claude Design without a solid brief. Instead of typing a long prompt from scratch, I dump all my unstructured thoughts, links, and background context into Claude Cowork and trigger my custom PRD-Writer Skill. This repeatable prompt automatically transforms my raw braindump into a standardized, structured PRD.

Step 2: The Data

A prototype is only as good as the data powering it. Rather than relying on generic “Lorem Ipsum” or fake data, I work with Claude to pull actual data directly from our data lake. Real data uncovers edge cases that clean dummy data easily hides. Where real data doesn’t exist, I ask Claude to generate realistic looking dummy data.

Step 3: The Design System

The legend that is Henry Franks on our team set up Claude Design with two versions of our design system: our polished production UI and a hand-drawn version. I almost exclusively use the hand-drawn template. Hand-drawn UIs keep feedback anchored on structure and value, giving designers the creative license to figure out how it should actually look and feel.

Step 4: Sit back and watch the magic happen

I upload the PRD, point Claude to the sample data, select the hand-drawn template, and let it build. Within minutes, I have a fully interactive UI ready for testing. It usually takes a few iterations to achieve what is in my head before it’s ready for sharing or testing with others.

Case studies

Here are some concrete examples which show how these capabilities are helping. For context, I lead product for a climate law and policy search platform. We turn long, unstructured PDF documents into structured, searchable data for global decision-makers. Here is how this workflow has played out in practice across four recent scenarios:

Case 1: Spotting Data Issues Early (HTML Reader vs. PDF)

As a GOV.UK alumnus and general accessibility advocate, I dislike PDFs. Most global laws, however, are trapped in them. I wanted to prototype an in-browser HTML document reader based on text we’d recently extracted. I needed to understand whether our data could support this type of reading experience, and gain a greater understanding of the shape of the data.

I fed real extracted data into Claude Design to render an HTML view alongside the original PDF. The prototype looked great, but not perfect. It helped me understand the gap between where our data is now, and where it needs to be to enable the type of reading experience I have in mind for our users. It also exposed an issue with how our data was structured. Seeing the data rendered visually allowed us to catch UX and data quality issues early.

Case 2: Resolving Internal Navigation Debates

We have over 100 machine-learning classifiers mapped to our knowledge graph. We have had many internal debates about how users should navigate this non-linear data, with strong opinions all round. Should we force it into a hierarchical tree? How do we handle multi-category items? Should every node in the tree be a text classifier? Many of the options would require weeks of data manipulation to enable, so this was not a decision that we wanted to get wrong. Many a notion document was written on the topic.

To break the deadlock, I generated three distinct navigation prototypes in Claude Design, based both on the data we had and the data we could have. Claude Design is collaborative, so other team members jumped in, tweaked my versions, and added their own. We quickly realised some of our bets just didn’t work, and some of the risks we were worrying so much about didn’t seem that risky after-all when we saw them in the light of day.

We are now more confident on the future direction is and is not. Critically, we have a way to quickly generate and test prototypes with users.

Case 3: Vision Prototyping

I like to give the team and senior leaders a sense of where the product is heading years from now so that we can align on the long term direction, generate excitement and make it easier to secure buy-in. Articulating a multi-year product vision usually means static slide decks or “postcards from the future.” Recently, while exploring a major new capability, I used Claude Design to build interactive vision prototypes.

Even though the underlying APIs and data structures don’t exist yet, Claude generated realistic interactive flows using synthetic data. Prototyping with senior stakeholders helped me get the ideas out of their heads and into a form we could all see, and helped us align around the future state we wanted to target. Being able to walk through dynamic and clickable interfaces helped us secure buy-in and minimise risk of misalignment.

Vision prototypes like these are a good example of where it might make sense to use the high fidelity design system in Claude rather than the hand drawn one. I can see huge potential in using prototypes like these in pitch decks.

Case 4: Failing faster and cheaper

As our database grows to include a wider variety of documents, I was worried users would hit “zero results” dead ends and assume our tool was broken. The textbook response is faceted search – a dynamic search which responds to the searches a user already has in place before a user clicks. I thought it was a must-have feature.

I decided to test the core assumption with Claude. I augmented our existing data with realistic synthetic data capturing the new data types we were planning to bring in and built two side-by-side low-fi prototypes: one faceted, one plain.

Quickly testing both prototypes made it clear to me that it wasn’t a must have after-all. At least not yet. It was a classic case of a product manager overthinking a problem. Prototyping with realistic data enabled me to figure this out faster and cheaper than I otherwise might have.

Why I’m Not Deploying Code to Production. Yet…

With AI tools making code generation trivial, it’s tempting to ask: why stop at low-fi prototypes?

I am still not writing production code. The one step forward we might gain by having me ship features solo would be offset by three steps back:

• Pushing AI slop into our codebase creates technical overhead that developers have to clean up. If I don’t have the skills to be held accountable for the code I commit, then I shouldn’t be committing it.
• Bypassing designers and engineers risks damaging team trust and downgrading the quality of our product.
• Every hour I spend acting as a second-rate developer or designer is an hour I’m not spending on strategy, discovery, user research or team alignment.

However, never say never. I can imagine a world where:

• The guardrails around AI tools and the alignment with our codebase makes it possible for me to write code that is understandable and maintainable by our engineers.
• Designers and engineers want me to be pushing low risk and experimental features myself, so that they can focus on the bigger problems.
• The costs of delay and translation exceed the costs of JFDI.

Overall, I love that Claude Design lowers the cost of discovery. For me right now the value lies in failing faster and cheaper together, not in replacing the cross-functional team with a one-man-band.