A prototype can be a sketch, paper flow, clickable mockup, or coded interaction. Its value comes from making an uncertain idea concrete enough to discuss or evaluate, not from looking finished.
A cardboard model of a room lets someone test its layout before construction. A product prototype offers a similar low-cost way to discover whether an idea makes sense before investing in a complete build.
State the question first
Decide what uncertainty the prototype should reduce. It might test whether people understand a label, whether a workflow is complete, or whether an interaction is technically feasible. A clear question guides the level of detail and keeps prototyping from becoming decoration.
Choose the lightest useful format
Paper can test sequence and concepts; a clickable prototype can test navigation; code can explore timing or technical behavior. Use the least expensive format that gives credible evidence. A high-fidelity mockup can distract participants if its polished appearance is not relevant to the question.
Make uncertainty visible
A prototype may omit real data, backend behavior, or edge cases. Tell participants and stakeholders what is simulated. Record assumptions and do not treat success in a simplified prototype as proof that a production service will work.
Learn and decide what happens next
After feedback, revise the idea, test a different direction, or stop. Preserve useful findings, but do not keep a throwaway prototype as production code without a deliberate quality review. The goal is a better decision, not a prototype that lives forever.
Frequently asked questions
Key takeaways
- Prototype to answer a defined question.
- Choose a format and fidelity that fit the evidence needed.
- Explain what the prototype simulates or leaves out.
- Use findings to decide whether to revise, build, or stop.