Prototype: make an idea concrete enough to examine

Choose the question before the format

A prototype is useful when discussion alone leaves too much room for different interpretations. People may agree that a booking should be simple while imagining entirely different steps. A model gives them something specific to use or examine. However, building a model without a question can produce a polished object that teaches the team very little.

Ask what you need to learn. Can people find a suitable appointment? Do they understand a status message? Will staff recognise an urgent case? The answer determines what you should model. If the uncertainty concerns wording, a detailed technical backend adds little. If it concerns physical reach, a screen mockup is unlikely to help.

Match detail to the uncertainty

A rough prototype makes it easy to change direction and can keep attention on the structure of an idea. A more realistic one may be necessary to examine interaction, content or timing. Neither level is automatically better. The useful question is whether the model represents the elements that could affect the observation you want to make.

For example, placeholder text can invalidate a check of whether customers understand an offer. Conversely, perfect typography may distract from a missing step in the process. Decide deliberately where realism matters and where a simple representation is enough. This keeps the effort proportional to the decision you are trying to support.

An illustrative equipment return example

Imagine a fictional tool hire shop redesigning the return process. The team creates paper screens showing a returned item, an inspection status and a next action. Staff members work through a scenario in which an item comes back damaged while another customer is waiting to hire it. They explain what they would do next.

The model reveals that “returned” is being confused with “available”. The team changes the wording and separates the two states before any production system is built. This is a useful finding about the proposed interaction. It does not establish that the eventual inventory connection will be reliable or that every staff member will interpret the system correctly.

Distinguish exploration from delivery

A proof of concept usually concentrates on whether an approach can work under defined conditions. A prototype makes an idea examinable, often with emphasis on interaction or form. An MVP offers a limited but coherent experience to learn from actual use. These purposes can overlap, but their evidence supports different conclusions.

Tell participants what is real and what is simulated. A clickable confirmation may not send a message, and a physical model may use materials unlike the final product. Such limits are acceptable when they fit the question. They become a problem when observers assume that an attractive demonstration proves the whole system is ready.

Give people a task, not a guided tour

To examine an interaction, describe a believable goal and let participants choose their route. “You need to move your appointment because your meeting changed” is more informative than instructions telling them which menu to open. Leading people through the intended path can make a confusing design appear clear because the facilitator supplies the missing explanation.

Observe hesitation, unexpected choices and attempts to recover. Ask neutral questions when you need to understand an action. This supports usability work, but a small exploratory session is not a population-wide measurement. Record the participants, context and version so you can interpret the observations within their actual limits.

Capture findings without defending the design

Separate what happened from what you think caused it. “The participant selected available immediately after recording damage” is an observation. “The status labels are unclear” is an interpretation to investigate. Keeping both makes discussion more useful and reduces the temptation to treat every surprising action as the participant’s mistake.

Group findings by the decision they affect. Some may require a wording change, others a different process or another question. Avoid fixing every comment immediately. One person’s preference for a colour is not equivalent to repeated difficulty completing an essential task. Consider the importance of the task and the strength of the evidence together.

Plan for the prototype to be temporary

A prototype often omits the work needed for dependable operation: access controls, error handling, monitoring, maintainability and complete data flows. If it later becomes a starting point for implementation, review those omissions explicitly. Do not let a convincing demonstration quietly become a production service simply because rebuilding feels inconvenient.

Use invented or appropriately prepared information when realistic personal data is unnecessary. Keep the model’s access and distribution appropriate to its purpose. A test artefact can contain misleading promises or unfinished instructions, so people outside the session should not accidentally encounter it as a real offer. Clear labelling helps preserve the boundary.

A test card for the damaged return

For the fictional tool-hire business, start with the paper design described above. This card makes the investigation repeatable without supplying its answer. Choose someone who handles returns, or is likely to do so, and use invented equipment records. Give the task without hinting at the desired status.

After the session, record what remains uncertain and what you will change or investigate next. A discarded model can still support a sound decision. Its value is the understanding gained, rather than the number of screens drawn or the amount of the first design retained.

• Question: can the person distinguish “returned” from “available for the next hire”? Participant role: [returns handling]. Model version: [date].
• Task: “A damaged tool is returned, and another customer is waiting for it. Handle the return and establish the next step.”
• Represented: equipment, inspection status and next action. Simulated only: the live inventory connection; the session does not book equipment or send a real customer message.
• Observe: first selected status, information sought and hesitation. Ask neutrally: “What do you expect now?” Do not explain which route would be correct.
• Record: [action actually taken or exact statement] separately from [possible explanation]. Selecting “available” immediately after reporting damage would be an example observation.
• Next decision: [change wording/change process/investigate further], supported by [observation]. Owner: [role]. Next check: [date and revised model version].