Question First
Stated before anything is built, so the result is interpretable.
Prototype Design
Prototype Design Built to Answer One Specific Question
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.
We Prototype the Question, Not the Product
Fidelity should be the minimum that produces a genuine answer.
Minimum Fidelity
Clickable screens where that suffices; nothing more elaborate than needed.
Tested With People
A prototype nobody tries is a presentation.
Cheap to Discard
Because the answer is sometimes that the approach was wrong.
Findings Documented
What was learned, so it survives the prototype.
What a prototype has to answer
A prototype is built to answer one question. Judged against that question it either resolves it or it does not; judged as a preview of the finished product it always disappoints. These checks keep it tied to its purpose.
Question statedThe specific uncertainty this prototype exists to resolve
Fidelity fitWhether the detail matches the question, rather than exceeding it
Realistic contentWhether it uses plausible data rather than ideal examples
Failure paths includedWhether the states being tested include things going wrong
Testable without narrationWhether a participant can use it unaided
Scope disciplineWhat was deliberately left out, and why
Technical plausibilityWhether what is demonstrated can actually be built
DisposabilityWhether it can be discarded without pressure to ship it
Findings recordedWhat was learned, tied to what was observed
Decision madeWhat changed as a result of building it
Technical plausibility is the check that prevents the most expensive failure: a prototype that tests beautifully, is approved, and then cannot be built as demonstrated. Involving whoever will implement it early costs little and avoids committing to an interaction the architecture cannot support.
Prototypes, Explained
What Can a Prototype Answer?
Four kinds of question, each suited to a different fidelity.
Discuss Your Prototype →- 1
Do People Understand It?
Answerable with static screens and a conversation.
- 2
Can They Complete It?
Needs clickable screens and a realistic task.
- 3
Does the Interaction Work?
Needs real behaviour, which is the expensive kind.
- 4
Is It Worth Building?
Needs enough realism that reactions are genuine.
What Prototype Work Covers
A prototype scoped to the question, plus the testing that answers it.
For validating with existing product users, see SaaS UX research. The structure being tested comes from wireframe design; the sessions themselves are usability testing.
How We Prototype
State the question, build the least that answers it, test it.
State the Question
Specific enough to be answered yes or no.
Choose Fidelity
The minimum that gives a real answer.
Build the Path
Only what the test touches.
Test
Real tasks, real participants, unguided.
Document
What was learned, separately from the prototype file.
What kind of uncertainty this resolves
Prototypes are worth building when something cannot be settled by discussion or by static screens. What kind of uncertainty it is determines what to build.
Flows that cannot be judged statically
Where the question is whether a sequence makes sense in motion. Static screens hide the experience of moving between them, and a clickable prototype answers in an afternoon what a review meeting cannot settle at all.
Novel interactions
Anything without an established pattern, where the team is genuinely unsure whether people will understand it. Here fidelity needs to be high enough for the interaction to be felt, since the question is about feel rather than structure.
Stakeholder alignment
Where people agree in principle and mean different things. A prototype makes the disagreement visible and specific before development turns it into rework, which is usually cheaper than another round of discussion.
Testing before committing to build
Where the feature is expensive and the demand is uncertain. Testing a prototype with real users is substantially cheaper than building the wrong thing, provided the test uses realistic tasks rather than a guided walkthrough.
Validating a technical approach
Where the uncertainty is whether something performs acceptably. This needs a functional prototype rather than a designed one, and it belongs closer to development than to design.
Fidelity
Why High Fidelity Too Early Costs More Than It Saves
A polished prototype changes the feedback and raises the cost of abandoning it.
What does polish do to feedback?
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.
Why does the question have to come first?
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.
Fidelity should match the question
Prototype fidelity is frequently chosen by habit or by what the tool makes easy, rather than by what needs answering. Both directions cost something. Too low, and participants react to the roughness instead of the interaction. Too high, and the effort invested makes the design harder to abandon and pulls feedback toward visual detail.
A structural question — does this sequence make sense — is answered by linked wireframes. A question about whether an interaction feels right needs enough realism that the motion and timing are genuine. A question about comprehension needs real content, because plausible-looking placeholder text is exactly what hides comprehension problems.
Deciding the question first and the fidelity second is what keeps prototypes cheap. Prototypes that grow in polish without a clear purpose tend to become de facto specifications, which is how untested details end up being built because they were in the file.
The prototype that becomes the product
A recurring failure is that a prototype built to explore an idea acquires enough polish that stakeholders treat it as the design. Development then proceeds from it, including every detail that was placeholder, unconsidered or deliberately simplified.
This is a communication problem more than a technical one. A prototype presented without framing looks like a finished product to anyone not involved in building it, and the natural response is to approve it. Stating explicitly what it does and does not represent — and what remains undecided — prevents most of it.
The related risk is the prototype that becomes the codebase. Code written to demonstrate an idea makes assumptions that production code cannot, and shipping it because it already works accumulates problems that surface later as instability. Prototypes are worth being explicitly disposable.
Testing prototypes without leading
The most common way prototype testing goes wrong is that the person running it explains as they go. It is natural — the prototype is incomplete, the participant hesitates, and the instinct is to help. Every explanation removes exactly the observation the session was run to obtain.
The discipline is to give a realistic task and stay quiet. Where a participant is stuck, the useful response is to ask what they expected to happen rather than to tell them what to do. Confusion is the finding, and rescuing someone from it destroys the data.
The second discipline is testing with realistic content. A prototype populated with ideal examples — short names, clean data, no edge cases — tests an experience that will not exist. Plausible content, including the awkward cases, is where comprehension problems actually surface.
Questions, answered.
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.
The minimum that answers the question. High fidelity shifts feedback toward styling and makes abandoning the approach feel expensive — which is exactly the answer a prototype exists to make cheap.
A wireframe is a static representation of structure; a prototype is interactive and demonstrates behaviour over time. Wireframes answer what goes where; prototypes answer whether the sequence works. Many projects need both, in that order, because it is cheaper to fix structure before making anything move.
Short enough that discarding it is not painful. A prototype that took weeks creates pressure to proceed with whatever it demonstrated, which defeats its purpose as an instrument for finding out you were wrong. If it is taking a long time, the question being asked is probably too broad.
Yes, and that is usually its highest-value use — provided the task is realistic and the facilitator does not narrate. Participants tolerate incompleteness well if told which parts are not built. What invalidates the session is guiding them past the confusion, which is the exact thing being measured.
Design tools are faster for flow and interaction questions, which is most of them. Code is warranted when the question is technical — whether something performs acceptably, whether a real dataset behaves as expected, whether a device capability works. Choosing code by default for design questions is usually slower without being more accurate.
The findings feed the design and the prototype itself is normally discarded. Keeping it as a reference is useful; treating it as a specification is where problems start, since it contains decisions that were never made deliberately. Anything from it that should be built needs recording as a decision in its own right.
Still deciding if prototype design is right for you?
Talk to UsIt Looked Nearly Finished
Prototypes 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.
Free Consultation
Talk Through What You Need to Find Out
Tell us what decision is waiting on evidence. We will scope a prototype to answer that question and test it with real users.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists