Question First
Stated before anything is built, so the result is interpretable.
A prototype exists to answer a question before something is built. Prototype design works when that question is stated first — will people understand this, can they complete it, is the sequence right — because a prototype trying to demonstrate everything demonstrates nothing testable.
Fidelity should be the minimum that produces a genuine answer.
Stated before anything is built, so the result is interpretable.
Clickable screens where that suffices; nothing more elaborate than needed.
A prototype nobody tries is a presentation.
Because the answer is sometimes that the approach was wrong.
What was learned, so it survives the prototype.
Four kinds of question, each suited to a different fidelity.
Discuss Your Prototype →Answerable with static screens and a conversation.
Needs clickable screens and a realistic task.
Needs real behaviour, which is the expensive kind.
Needs enough realism that reactions are genuine.
A prototype scoped to the question, plus the testing that answers it.
For validating with existing product users, see SaaS UX research.
State the question, build the least that answers it, test it.
Specific enough to be answered yes or no.
The minimum that gives a real answer.
Only what the test touches.
Real tasks, real participants, unguided.
What was learned, separately from the prototype file.
A polished prototype changes the feedback and raises the cost of abandoning it.
It makes people respond to the design rather than to the idea. A rough prototype invites structural criticism; a finished-looking one invites comments about colour and spacing.
It also implies the decision has been made. Participants and stakeholders alike are less likely to say the whole approach is wrong when it looks nearly built.
For a question about comprehension or sequence, low fidelity produces better answers as well as costing less — the roughness is doing useful work.
Because it determines what the prototype needs to contain, and without it the prototype grows to cover everything.
A prototype demonstrating the whole product takes weeks, tests nothing specific, and produces feedback too diffuse to act on.
One question — can a new user complete setup without help — scopes the build to one path and produces an answer that changes what gets built.







Prototype design builds an interactive representation of a design to answer a specific question before development, tested with people from the intended audience.
The minimum that produces a real answer. High fidelity too early shifts feedback toward styling and makes abandoning the approach feel more costly than it is.
Yes — an untested prototype is a presentation. The value is entirely in what happens when someone from the intended audience tries to use it.
One, stated before it is built. Without that, the prototype grows to demonstrate everything and produces feedback too diffuse to act on.
Wireframes settle what is on each screen; prototypes test whether the arrangement works when someone tries to use it.
Still deciding if prototype design is right for you?
Talk to UsPrototypes get built to a high standard because the tools make it easy and because a polished artefact is easier to present internally.
Polish changes what people say about it. A rough prototype invites someone to question the approach; one that looks nearly built invites comments about the shade of the button.
It also raises the cost of hearing that the whole idea is wrong, which is exactly the answer a prototype exists to make cheap. The more finished it looks, the less likely anyone is to say it.
Tell us what decision is waiting on evidence. We will scope a prototype to answer that question and test it with real users.
