A prototype has one job: to settle a question you can name before you start.
Write that sentence and the rest follows from it. The fidelity, the tool, the deadline and the people you show it to are all decided by what you need to learn.
Skip it and you’ve built a demo. A demo gets admired, and admiration doesn’t answer anything.
Key Takeaways
- Writing the question first decides the fidelity, the tool and the deadline.
- Choosing paper for round one settles layout faster than any software will.
- Polishing early buys polite feedback instead of the criticism you needed.
- Deciding throwaway or evolutionary up front stops a demo becoming the product.
Write the Question First
One sentence, on paper, before anything gets built.
“Can a new user find the export button without help?” is a question a prototype settles. “What should the dashboard look like?” isn’t, because there’s no answer that would ever count as no.
A prototype without a written question turns into a demo, and a demo gets admired rather than tested. That’s the failure behind most of the time people lose here.
Its Place in the Build
After the problem is agreed and before anybody commits to an approach.
Prototyping too early produces a picture of a problem nobody has defined, and everyone reviews it against a different idea of what’s being solved. Prototyping too late means the architecture is chosen and the answer can’t change anything.
The useful window is narrow. The team agrees what the problem is, nobody has committed to how, and the cost of being wrong is still a week rather than a quarter.
One test tells you if you’re in it. Ask what would change if the prototype came back negative. If the answer is nothing, you’re past the window.
Fidelity Follows the Question
Pick the cheapest thing that can answer what you asked.
| Question shape | Fidelity | Build time |
|---|---|---|
| Does the order of steps make sense? | Paper sketches | An hour |
| Can people find their way through it? | Clickable wireframes | One to two days |
| Do people understand what it does? | Styled mockup | Three to five days |
| Will it hold up with real data? | Working no-code build | One to two weeks |
Reading that table upwards is the mistake to avoid. Teams pick a fidelity they’re comfortable building and then invent a question to justify it.
Paper Still Wins Round One
It’s faster, it’s free, and it gets you better feedback than anything on a screen.
Sketches invite correction. Somebody will take a pen to a paper flow and reorder it in front of you, and nobody does that to a screen that looks finished.
Round one is nearly always a sequencing question: what comes first, what can be skipped, what belongs on one screen. Paper answers that in an afternoon.
The Polish Trap
The better a prototype looks, the worse the feedback gets.
Show somebody a styled screen and they comment on the shade of the button, because the layout reads as decided. Show them a grey wireframe and they tell you the step is in the wrong place.
Polish signals that the decision is closed. If you want the flow challenged, keep it visibly unfinished, and save the styled version for the question about comprehension.
Throwaway or Evolutionary Is a Commitment
The distinction is about what happens afterwards, not about how it’s built.
A throwaway prototype gets deleted the day it answers its question. That’s the point of it, and it’s why it can cut every corner that doesn’t affect the answer.
An evolutionary prototype becomes the product, so it carries production standards from the first line and costs three or four times more. Both are fine. Deciding by accident is not.
The accident has a shape: a throwaway gets demoed, somebody senior likes it, and it ships. Naming the choice out loud on day one is what prevents it.
The Third Kind Nobody Mentions
Incremental prototyping sits between the other two and suits long builds.
Instead of one prototype for the whole product, each piece gets its own as it comes up, and each is thrown away once its question is settled. The product gets built conventionally alongside.
It costs more in total than a single throwaway and less than an evolutionary build. It fits work where the unknowns arrive in sequence rather than all at once, which describes most projects longer than a quarter.
Building It Without Code
The working-build row of that table is the one that changed most.
A no-code platform will get a real, clicking, data-holding version of a narrow flow in front of people inside a fortnight, which used to need a developer. That’s enough to answer questions paper can’t reach, like whether people trust the thing with real inputs.
The no-code development platform category is where those tools sit, and the same build approach powers the AI website builders people use for landing pages. Keep the scope to one flow, because a no-code build that spreads becomes an evolutionary prototype without anyone deciding it should.
Prototyping With AI Tools
Generated screens changed the first day of this work and not much after it.
Describe a flow and you’ll get plausible screens back in minutes, which is genuinely faster than sketching for anyone who can’t draw. That gets you to something reviewable sooner.
What it doesn’t do is decide anything. The output arrives already polished, which walks straight into the trap above.
A generated screen looks finished, so it collects opinions on styling rather than challenges to the flow.
Use it for the draft and then rough it up. Strip the colour and the copy before showing it to anyone whose job is to tell you the order is wrong.
Who to Put In Front of It
People who’d use the thing, and nobody who helped design it.
Colleagues know what the buttons mean before they read them, so they can’t get lost, and getting lost is the entire signal you came for. A prototype tested internally reliably passes.
Five people from the actual audience beats twenty from the building.
If the real audience is hard to reach, the nearest honest substitute is somebody holding the same job title elsewhere. Note in the write-up that you used a substitute.
Recruit for the task, not the demographic. Somebody who has genuinely needed to do this job in the last month will find things that a matched profile who hasn’t will walk straight past.
Making the Prototype Lie Less
Placeholder content hides most of the problems you’re looking for.
Filler text and neat sample names produce a screen where everything fits, and real data doesn’t behave. Names run long, prices carry more digits than expected, and lists arrive empty on a new account.
Put three awkward records in before anyone sees it: the longest name you can find, a value with more digits than the column expects, and an empty state. Those three catch more layout problems than another round of sketching.
What It Costs in Hours
Budget the review, not only the build.
- Writing the question and the task list, about two hours.
- Building at the chosen fidelity, an hour to two weeks.
- Running five sessions, roughly four hours including scheduling.
- Writing up what was decided, about two hours.
The last line is the one that gets dropped, and dropping it is what makes a prototype feel like wasted effort a month later.
Running the Session
Give people a task and then stop talking.
Don’t demo it. Hand over the prototype with one instruction, like “buy a ticket for Thursday”, and watch where they hesitate. The hesitation is the finding, not what they say afterwards.
Five people is enough to surface the bulk of the problems in a single flow. After that you hear the same issues again, which is reassuring and not new information.
Testing a prototype is the same discipline as software quality assurance applied earlier, and with the same rule: the thing you’re testing is the product, not the person.
Three Times Not to Prototype
Three cases where it’s the wrong tool.
The first is when shipping the real thing is cheaper. A small feature behind a flag reaches real users faster than a prototype reaches five recruited ones.
The second is a demand question. Whether people want it at all is answered by a landing page and a signup count, not by a flow nobody has asked for yet.
The third is when the decision is already made. A prototype built to confirm something reads as theatre to everyone in the room, and it costs the same as a real one.
What It Has to Produce
A file is not the deliverable. A decision is.
When it’s finished you should be able to write down the question, the answer, and what changes as a result. Three lines, circulated, is what turns a week of prototyping into something the next person can build on.
Without that, the prototype survives as a link in a chat thread and gets reopened six months later by somebody trying to work out what was concluded.
Questions People Ask About Software Prototypes
What is a software prototype?
A software prototype is a working stand-in for part of a product, built to test an idea before anyone writes production code. It can be paper, a clickable mockup or a rough no-code build.
How long should a prototype take?
A day for paper, two to three days for a clickable mockup, and one to two weeks for a working no-code build. Anything longer usually means the question got lost.
Throwaway or evolutionary: what’s the difference?
A throwaway prototype gets discarded once it answers its question. An evolutionary one becomes the product, so it carries production standards and costs more from day one.
Do I need a prototyping tool?
Not for the first round. Paper or a whiteboard settles layout and flow questions faster, and tools earn their place once you need people to click through something on their own.
How large should a prototype test group be?
Five is enough to find the bulk of the problems in a flow. Beyond that you hear the same issues repeated rather than new ones.
Start With the Sentence
The tool matters less than the question, and the question takes ten minutes to write.
Name what you need to learn, pick the cheapest fidelity that can answer it, show it to five people, and write down what you decided. That’s the whole method, and the rest is preference.
Add SocialAtoZ as a preferred source
See us more often in your Google results.
