From rapid prototyping to rapid learning

Three weeks. That’s how long it took to go from first experiment to creating Design System-based React prototypes I can click through and test. The speed surprised me. What I learned along the way surprised me more.

The biggest shift isn’t the output. It’s what disappears.

In the traditional version of this work, I would have met with a designer and tech lead. A couple of check-ins on progress, questions answered in chat and in person. Then a handover to development, together with the designer. Best case, we’d have a Figma clickable prototype - but likely not. The developer would have questions about things we hadn’t thought of, because we hadn’t tested the flow interactively. The feedback loop stretches across days or weeks, and every handover is a chance for context to get lost.

Now: I have an idea. I prompt. I see it. I click through. I notice a problem - maybe a missing screen I hadn’t considered, maybe a flow that dead-ends. I iterate. I prompt again. I learn.

One moment made this concrete: I was clicking through a prototype and realised I forgot a screen. The prototype showed me a gap I might have forgotten in a document or a discussion. I fixed it in minutes and kept going.

The time compression matters, but it’s not the real value. The real value is uninterrupted thinking. When I stay in one context - prompting, testing, iterating - I’m not waiting for someone else’s calendar. I’m not context-switching between meetings. I’m not re-explaining what I meant three days ago.

The thinking and the testing happen together. The iteration is the thinking.

And because alternatives are cheap, I don’t commit to one direction early. I can build two or three approaches and see which one breaks first, rather than debating in the abstract. This is what “rapid learning” actually means. Not just fast output - fast feedback. The loop between idea and reality shrinks to minutes instead of days.

The journey: three versions in three weeks

v1. It started with copying an approach I saw Teresa Torres demonstrate - using Claude to create local markdown files for user stories and epics. Simple, but it made me wonder: what’s possible beyond .md files?

v2. was barebone HTML prototypes with a simple wireframe design system. The interesting part wasn’t the output quality - it was how easy it became to explore alternatives.

v3. Design System-based React prototypes using the Elisa Design System through a Storybook MCP integration (not yet officially supported). This is when I started to see it, the vision I had four years ago when I started leading the Design System team.

I want to be honest about the limitations. I’m not a developer, and that showed. The AI can do a lot, but it can’t always debug its own failures. And this approach works best for exploring and learning - it’s not a replacement for proper design process or development rigour.

But for the early stages of product thinking - when you’re trying to understand the problem, not ship the solution - this changes the game.

If you’re curious: start with a small experiment. Copy someone else’s approach. Iterate and learn as you go. And find a developer friend for when Claude starts looping.