One way to approach prototyping

I’ve been prototyping a lot more with AI recently, particularly with tools like Figma Make. One thing I’ve noticed is that there’s a point where continuing to iterate on the same prototype stops being useful.

You know the point.

You’ve added features. Changed the navigation. Reworked a few interactions. Asked AI to undo something it did five prompts ago. Fixed one thing and somehow broken another.

The prototype still works. Sort of.

But it’s carrying a lot of history.

I used to keep pushing at this point. Now I’m trying something different.

I ask AI to write a PRD based on what we’ve built and learnt so far.

Then I start again.

The prototype becomes part of the thinking

We normally think about the process roughly like this:

PRD → Design → Prototype → Build

The requirements come first. The prototype is an expression of those requirements.

AI prototyping has made me question that order.

I’m increasingly working like this:

Idea → Prototype → Learn → PRD → New prototype → Learn again

The first prototype doesn’t need to be right.

Its job is to help me work out what the product should be.

Once I can click through something, I start noticing things I hadn’t considered.

• What happens after this action?
• What does this screen look like with real data?
• Which states are missing?
• Does this interaction still make sense when the workflow gets more complicated?
• Was that feature I thought I needed even useful?

Those answers become requirements.

Then I get AI to document what we’ve learnt

This originally started as a practical trick for Figma Make.

I found that the longer I worked on a prototype, the more context and code it accumulated. If I ended up stuck in a loop of errors, sometimes the better option was to stop trying to fix it.

My original note to myself was:

Ask AI to write out a PRD and use it in a new file.

That turned out to be useful for more than escaping a broken prototype.

The PRD became a way of taking everything useful from an iteration and leaving the mess behind.

I don’t need every prompt.

I don’t need every failed experiment.

I don’t need the implementation decision AI made 40 prompts ago because I vaguely asked it to “make this work better”.

I need the things we’ve decided are worth keeping.

So the PRD becomes a checkpoint.

Starting again isn’t starting again

This is probably the bit I find most interesting.

Throwing away a prototype used to feel wasteful.

Now I don’t think it is.

If the prototype helped me understand the product better, it did its job.

The artefact isn’t the only valuable thing that came out of the work.

The learning is valuable too.

And by turning that learning into a PRD, I can feed it straight into the next iteration.

So instead of endlessly improving Prototype V1, I can start Prototype V2 with much better context.

Then V2 teaches me something new.

That feeds V3.

Idea → Prototype → Learn → PRD → Clean start → Better prototype → Learn → Repeat

It’s changed how I think about PRDs

I used to think of a PRD mainly as an input into design.

Now I’m starting to see it as something that can also come out of design.

You build enough to expose the questions.

You click around.

You find the awkward bits.

You change your mind.

Then you document what survived.

That document becomes the starting point for the next round.

And because AI makes both creating the prototype and documenting it much cheaper, the loop can happen much more often.

For me, that’s becoming one of the more useful patterns in AI prototyping.

Don’t try to make the first prototype perfect. Make it useful enough to teach you what the second one needs to be.

That feels much closer to how I want to work.