How Claude AI Prototyping Changed My Product Workflow
How Claude AI Prototyping Changed My Product Workflow
Throughout the autumn of 2025 I’d been reading more about how AI was becoming an essential tool for Product Managers to validate ideas through prototyping. Previously PM teams would work with designers and developers to visualise concepts, run tests and validate, often with A/B testing. I don’t have the luxury of those resources in my main role, but I do work in a fast-paced environment where features ship in under two weeks, and I have a smaller internal team to test on before we release to clients. I wanted to see what prototyping with AI could do.
Like a lot of people, 2025 was a breakthrough year for me with AI. It went from ad-hoc use (writing documents, letters, poems) to no and low code solutions like VisaScope AI, to full-on vibe coding. Coming from a background of coding and building products from scratch, I was initially sceptical about SaaS products combining to create complex workflows and even more so about AI building whole products given the pitfalls I’d seen writing JavaScript, CSS and HTML with Claude. I was happy to be proved wrong. It opened up a way to bring ideas to life without dev resource and I’ve been waiting for ideas worth testing before taking on bigger vibe coding projects. Now I have those ideas, which I’ll cover in upcoming posts.
One step that got me there was prototyping. In this post I want to cover three of the many prototypes I’ve built: how I’ve used them to save time, better translate my ideas for stakeholders and developers, and how this has led me to take on bigger projects.
When I embarked on the Nucleus Admin redesign, designers were commissioned to provide the initial screens. They weren’t 100% accurate, but they were aligned enough with Nucleus content that stakeholders could visualise and provide feedback.
As we prepare to redesign the events admin interface using the same design template, I wanted to achieve the same and demonstrate how the menus would align. Previously I would work it all out in Confluence in writing, but that doesn’t support visualisation.
So I gave my initial requirements to Claude and asked it to mock up a webpage. Claude was remarkably accurate on the first pass. I then took some screenshots of Nucleus and added them to the prompt and Claude quickly updated the colours and designs to match. A few more prompts and about an hour’s work and I had a clickable prototype ready to distribute.
It’s not pixel perfect, but it gives admins a clear view of what’s coming and a concrete basis for feedback. Interestingly, I know it’s landed well because the only criticism has been the pixel accuracy. The menus themselves work. To mock this up with a developer would have cost significantly more and I could have produced four or five alternatives in half a day to give stakeholders choice.
It demonstrated the value of rapid prototyping for me, and surfaced gaps in the menus and potential implementation issues before any dev work began. I’ll definitely be using this approach again to better translate requirements for stakeholders, developers and designers.
When I was studying for my PSPO 1 exam last year, I very quickly ran out of practice questions. I found more question sets I could purchase but I wasn’t enjoying the writing style, so I took to Claude and ChatGPT to explain my situation. Within minutes Claude had me up and running with a prototype.
I worked with ChatGPT to design how the questions should work and the JSON structure. A few more instructions with Claude and I had a well-defined prototype ready to use. The only gap was the questions themselves.
I spent an evening working with ChatGPT to build a Make workflow with two agents to write the questions, but realised as I was validating them this was overkill. I just needed to ask Claude and ChatGPT to write the questions and get each one to validate they were correct. My only prompting was guiding them on the topic areas the questions needed to cover.
I ended up with a bank of 500 questions. This saved money, but more importantly gave me an unlimited, extensible question set. The part I particularly liked was creating a store so questions could be uploaded incrementally, meaning I could add new ones as I wanted. I also specified the UI to support both quick-fire practice rounds and full-length exam simulations.
We’re currently building a complex feature set in Nucleus to consolidate functionality from different settings spaces into one coherent section. Nucleus has no concept of rounds, so even though judges can view content, vote, provide scores and comments, there’s no scope for controlling when periods end programmatically. Either viewing is on or off, or judges have rights or they don’t.
For several years I’ve been wanting to introduce rounds: allowing admins to define time-boxed periods for each action. There might be a round 1 of voting for a month, followed by a round 2. This is currently possible but the setup is lengthy and complex. My aim was to consolidate it all into one page.
When I began writing tickets, I hit two problems: it was challenging to visualise all the functionality, the order and how it would look, and I ended up with huge tickets that are difficult for developers to parse and implement. Plus, most likely when I did see the UI I would require changes and tweaks.
So I decided to vibe code a prototype of the page with all the elements needed, enough visualisation for developers to understand how to implement. The initial build took me two hours, but I refined it over the course of a week, reviewing and coming back.
This approach ensured all the functionality I needed was included, but it also meant I could workshop ideas. At one stage I had two tables for a process and then managed to reduce it to one. Each time I hit a roadblock I could see it, work with AI to tweak it, or have a quick call with the developers to resolve it.
This saves significant implementation time and avoids rewriting code when a feature I specified doesn’t work as well as I’d imagined once built. It also shows developers the exact components needed and the order of the build. It’s not pixel perfect, but that’s not the aim: build, test and iterate quickly without using dev resources.
This last example is particularly powerful and I’ll be using this approach more. If a client requires a new feature, I can show them how it might look and they can provide immediate feedback. I can work with clients to refine everything before they sign off. This gives clients more confidence and better visibility of what they’re working with, and more information to decide whether to progress.
If you haven’t tried prototyping with AI, I’d encourage you to, and I’m happy to assist in any way I can. Prototypes are one way I’ll be improving my processes, and the foundation for the bigger vibe coding projects I’ll be sharing soon.
