How to test an idea with a prototype before development

To test an idea with a prototype, define one question, make a model clear enough to investigate it and ask a likely user to attempt a specific task. Observe actions and difficulties. A prototype tests a chosen part of a solution; a positive response does not establish demand or prove that the whole product is ready.

Start with an assumption, not a mock-up

Suppose you want to simplify room reservations for a small club. Before building a system, identify what you do not know. Can members understand available time slots, choose an appropriate duration or tell what happens after submitting a request?

Select one question: “Can a member find a suitable slot and understand whether the reservation is confirmed?” That tells you which parts of the model are needed. A complete account area and polished versions of every page are not yet necessary for this check.

Separate questions about usability, technical feasibility and the need for the service itself. One mock-up cannot answer all of them. Successfully choosing a time does not establish that people would use the system regularly.

Build a model that fits the question

The GOV.UK Service Manual describes prototypes ranging from paper sketches to interactive code, with the form chosen to suit the current need. A functioning application is not required for every idea.

For the club example, prepare a few screens: the timetable, time selection and the request outcome. Use fictional names and entries so that nobody mistakes the session for an actual reservation. Distinguish “request sent” from “place confirmed” if those are different states in the proposed process.

A draft message may be sufficient to examine whether a letter is understandable. A role-play can explore a task handover. The GOV.UK guide to prototyping ideas includes these kinds of format. Use enough detail to make the action you need to observe possible.

If you are unsure whether a draft is enough or interaction is needed, use the prototype format comparison. It connects the choice to the particular action you need to observe.

Give a task without revealing the solution

Invite someone familiar with the relevant situation to try the model. Explain that the design, rather than their ability, is being examined. Giving a task and observing the attempt is the approach described in GOV.UK’s usability-testing guidance.

A neutral task for the example could be: “You need a room for an hour on Tuesday evening. Show how you would choose a time and find out whether you can attend.” Saying “Click the green button, then confirm” reveals the route and prevents you from checking whether it is understandable.

Record where the participant pauses, what they expect and any help they need. If you help them continue, note the intervention. Do not record assisted completion as fully independent use.

Separate observation from explanation

An observation: the participant treats the request-submitted message as confirmation. A possible explanation: the wording sounds like a final answer. A next check: change the text and observe how it is understood. Whether the same problem occurs in the real process remains an open question.

“Do you like it?” can contribute to a conversation, but cannot replace an attempt to complete the task. For follow-up questions, see the guide to asking for useful feedback.

A few sessions can uncover difficulties; they cannot tell you what percentage of all future users will experience them. Avoid turning an individual response into a claim about the market. Record the model’s limitations too, including parts that were simulated or did not function.

Decide what follows the test

You might clarify the wording, try a different sequence, investigate another assumption or abandon the solution. If the question remains unanswered, examine whether the prototype prevented a useful attempt or whether you chose the wrong task.

A concise record could say: “The request status was unclear. Revise the message and check whether people distinguish submission from confirmation. Demand and technical implementation have not been assessed.” This is more useful than a general note that people liked the idea.

If the test went poorly, use the guide to reviewing assumptions after an unsuccessful attempt. Moving into development is a separate decision. Make it with a clear account of what has been examined and what remains unknown.