I do not start a prototype by asking how polished it should look. I start by asking what the team needs to learn.
That decides what I build and how much time it deserves.
Pick one uncertainty
A prototype needs one clear job. We might compare two journey structures, test whether the language makes sense, or show engineering how an interaction should behave.
I write that question at the top of the file. It stops the prototype growing into a complete product.
For flow and content, linked frames are usually enough. For keyboard behaviour, responsive layouts, animation, or complex states, I build a coded prototype.
The coded version shows what happens when content wraps, data changes, or an action fails. I include difficult examples such as long names, missing information, and returning to an interrupted journey.
Put it in front of the right people
Customers tell us whether the journey is clear. Engineers find technical gaps. Operations teams spot support problems. Risk teams can respond to the actual flow instead of interpreting a presentation.
I record what the prototype confirmed, what changed, and what remains open. The prototype can then be thrown away without losing the decision.
The useful output is the decision, not the prototype.