An innovation prototype is a limited representation of an idea used to answer a question before committing to wider implementation. It can be a paper process, a service rehearsal or a simple model. This article explains how to choose the question, design the test and use the findings without mistaking an attractive demonstration for evidence of demand or operating readiness and scalability.
Start with the uncertainty that matters
An idea can contain several assumptions: customers understand it, they value it, staff can deliver it and the expected value justifies delivery and operating costs. One prototype rarely tests all of them. Choose the uncertainty that could most change the decision to proceed.
For example, before building a booking application, a service team might ask whether customers understand a proposed appointment-choice process. A paper screen or manually supported demonstration may answer that question. It will not establish the security, reliability or capacity of a future production system.
Choose the simplest useful representation
Nesta describes prototyping as an early way to develop, test and improve an idea before extensive resources are committed. The form should follow the question. A physical model may test handling; a role-play may test a service handover; a sample message may test understanding.
Distinguish a prototype from a pilot. A pilot usually tries a limited operational implementation under more realistic conditions. Both need clear boundaries, but a convincing prototype is not proof that the service can operate reliably at scale.
Write a test card before inviting participants
A test card connects the question, task, evidence and next decision. Write it before the sessions to avoid changing the success criteria after seeing the results. One clear page answering the following questions is enough:
- Question: what uncertainty will the test address?
- Participants: whose experience is relevant, and who is missing?
- Task: what will participants actually try?
- Observation: what behaviour or evidence will be recorded?
- Decision: what findings would support changing, continuing or stopping?
Specify the boundary, time and responsible owner. Explain the prototype’s status to participants, obtain appropriate permissions and avoid collecting unnecessary personal information. Do not expose people to an unsafe or misleading live service under the label of experimentation.
Worked example: appointment instructions
A fictional maintenance provider wants to reduce confusion about appointment preparation. It creates a paper message showing what the customer needs to provide before the visit. The question is whether customers can identify the required preparation without staff explanation.
The team asks each participant in a small group of potential customers to explain what they would do next. It observes where they hesitate or misunderstand. Rather than asking only “Do you like it?”, it gives them a realistic task and records what they can complete.
The team defines independent understanding in advance: stating the appointment, preparation requirements and technician access arrangements without hints from the facilitator. The facilitator is the person who leads the session and presents the task neutrally. For each participant, they record what was understood unaided, what needed explanation and what was misunderstood. These are educational criteria for this example, not a general service-quality benchmark.
If several people miss the access requirement, the team revises its position and wording, then tests again. The prototype supports learning about comprehension. It does not prove a reduction in missed appointments, which would require a later operational test and a suitable comparison. This educational example does not report results from a real organisation.
Separate observations from interpretations
| Record type | Illustrative entry |
|---|---|
| Observation | A participant overlooked the access instruction |
| Interpretation | The instruction may be too far from the appointment details |
| Change | Move and simplify the instruction |
| Next check | Test whether new participants notice and explain it |
Keep disconfirming evidence. A team invested in its idea may explain away confusion instead of learning from it. Record what surprised you, alternative explanations and whether assistance from the facilitator changed the result. Do not present task completion after prompting as independent user understanding.
Understand the limits of a small test
A small convenience group is not automatically representative of every customer. Participants may be unusually motivated, technically confident or familiar with the organisation. Record these limits and include relevant access and language needs in later testing.
Do not turn a few positive comments into a market-size estimate or a revenue forecast. Nor should one negative reaction automatically kill an idea. Examine whether the reaction concerns the underlying need, the proposed solution or a fixable detail in the prototype.
For regulated, safety-critical or sensitive activities, involve the necessary expertise before testing. A low-cost prototype can still create real risks if it uses live personal data, makes misleading promises or changes a process on which people depend.
Record the version before testing again
Keep a dated copy of the message or screen each participant saw and link the observations to it. If wording changes between sessions without a record, it becomes difficult to identify which version caused confusion and which revision helped. Record the facilitator’s instructions and any assistance provided.
In the appointment example, returning participants may remember the access requirement from the first test. Do not attribute all improvement to the new wording. Use new participants when assessing first-use comprehension, or explicitly state that the test concerns learning through repeated use. Close each cycle with an evidence-linked decision: which change stays, which question needs another test and who owns the next version?
Choose the next level of commitment
In the message example, continued misunderstanding of access instructions calls for revision and another test. Understanding them without assistance supports a bounded pilot, but does not establish success of the entire service. If evidence remains insufficient, record what is missing before extending the commitment.
After the test, decide whether to revise the prototype, investigate a different assumption, move to a bounded pilot or stop. State what has been learned and what remains unproven. The next investment should match the strength of the evidence and the consequence of being wrong.
If moving to a pilot, define operating responsibility, support, rollback arrangements and the measures needed to assess real use. Avoid quietly turning an experimental workaround into a permanent service without reviewing its reliability and maintenance needs.
Start by writing one test card for an existing idea. Connect it to the priorities in your innovation strategy. ATMACSS innovation and future foresight support can help structure assumptions, experiments and the decisions that follow.