A prototype should answer a question that is expensive to leave open.
That is its job.
The question might be technical. Can the browser handle the motion without making the page feel heavy? Can the data arrive quickly enough to make the experience useful? Can an AI system produce a dependable first draft from the source material the team actually has?
It might be about behavior. Will a customer understand the new intake flow? Can an editor publish without calling a developer? Will the sales team use the tool when a real opportunity is moving?
It might be about production. Can the team generate the required images consistently? Can one content model support the website, email, and sales materials? Can the hard interaction work on a small screen before the rest of the page is designed?
These are good prototype questions because the answers change the plan.
If the answer is no, the team can revise the idea while the cost is still contained. If the answer is yes, the team has evidence for the next investment. Either result is useful.
Teams usually get prototypes wrong by asking them to look finished.
The prototype gets a name, a polished interface, sample content, account settings, and enough surrounding detail to make it presentable. Stakeholders begin giving feedback on color, wording, and edge cases. The team starts protecting work that was supposed to be temporary.
Soon the prototype is carrying two jobs. It is expected to reduce uncertainty and persuade the room that the project deserves to continue.
Those jobs can conflict.
A persuasive demo hides rough edges. A useful prototype exposes them. A persuasive demo keeps the happy path moving. A useful prototype puts pressure on the part most likely to fail. A persuasive demo invites approval. A useful prototype produces information.
There is nothing wrong with a polished demonstration when the team needs one. It simply should not be confused with a prototype.
The better way to think about prototyping is as a small decision system.
Start with the decision the team cannot make confidently. Then name the uncertainty blocking it. Build only enough to test that uncertainty under realistic conditions.
Suppose a company wants an AI assistant to help account teams prepare client briefs. The prototype does not need a complete chat interface, user profiles, or a library of prompts. It needs representative source material, a defined brief format, a review standard, and a small set of real cases.
The important questions are plain. Does the source material contain what the brief requires? Does the system distinguish facts from guesses? How much correction does a good reviewer make? Is that correction smaller than the work the tool removes?
If the team cannot answer those questions, interface polish will not rescue the idea.
The same principle applies to websites.
A team considering an unusual interactive feature may not need to prototype the whole page. It may need one isolated browser test that covers motion, touch behavior, reduced-motion settings, loading time, and the smallest screen the feature must support.
That test can be unattractive. It can use temporary controls and plain shapes. Its value comes from making the hard part visible early.
Internal tools need the same discipline.
If a publishing process is slow because editors cannot preview structured content, test the preview and approval path first. Do not begin by recreating every feature of the current system. If a reporting tool is meant to replace a spreadsheet, test whether it supports the decision people make from that spreadsheet. Do not start by reproducing every column.
The prototype should be smaller than the ambition.
That is not a lack of commitment. It is how commitment becomes informed.
A good prototype also needs an exit condition. Before the test begins, the team should agree on what evidence will support the next move.
That may be a performance threshold. A successful completion rate. A reduction in review time. A clear answer from five representative cases. It may be a finding that the source data is not ready, the interaction is too fragile, or the operating cost is larger than the value.
The exit condition does not need to be a perfect score. It needs to be specific enough that the team can stop testing and decide.
Without that condition, prototypes linger.
People add features because the answer still feels incomplete. The test becomes a small product with no owner. Temporary code enters production because rebuilding it seems wasteful. The team spends more money improving an experiment than it would have spent making the original decision clearly.
Some prototype code should be discarded.
That can feel inefficient, especially when the test worked. But the prototype may have been built for speed of learning, not durability, security, maintenance, or scale. Keeping it without review turns a useful shortcut into a long-term constraint.
The artifact is not the only thing the team paid for.
It paid for the answer.
The practical next step is to take the riskiest assumption in the proposed work and write it as one question.
Then define the smallest realistic test, the evidence required, the person who will decide, and the date when the prototype ends.
If the team cannot write the question, it is not ready to build the prototype.