I do not start a prototype by asking how polished it should look. I start by asking what the team needs to learn.
That question decides what I build, who needs to see it, and how much time it deserves.
Pick one uncertainty
A prototype works best when it has a clear job. We might need to compare two journey structures, test whether the language makes sense, or show engineering how an interaction should behave.
I write the question at the top of the working file. This stops the prototype growing into a complete product that nobody asked for.
Match the fidelity to the decision
For flow and content, linked frames are usually enough. They are quick to change and keep feedback focused on the journey.
For keyboard behaviour, responsive layouts, animation, or complex states, I build a coded prototype. It can show what happens when content wraps, data changes, or an action fails. Static screens cannot explain those details properly.
I use realistic content and include a few difficult scenarios. Long names, missing information, errors, and returning to a journey often expose more than the perfect path.
Use it with the right people
Customers help us understand whether the journey is clear. Engineers find technical gaps. Operations teams recognise support problems. Risk and control 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 output is not the prototype. The output is a question answered early enough to change the work.