How to choose a prototype format for your question
Text, paper, interactive models or scenarios matched to the action you need to observe
The takeaway
Choose the format around an observable action. Add the detail needed for that check and record which conclusions the model cannot support.
Choose a prototype format according to the question you need to answer. A text draft can test the meaning of a message, a sequence of screens can support a discussion of the journey, and an interactive model can let you observe actions. More elaborate models require more preparation. Add detail when the intended check depends on it.
Describe the action you need to observe
Start with “The person needs to be able to…”. They might need to understand the requirements for a volunteer shift, choose a time or correct information entered incorrectly. Those questions require different models, even when they concern the same future service.
Record what the model will not test. A timetable mock-up does not establish how a system handles load. Understanding an invitation does not show how many people will attend. For designing the test itself, follow the guide to testing an idea with a prototype.
The GOV.UK Service Manual describes formats ranging from paper sketches to code prototypes. Match the format to the current research question; resemblance to a finished product is not an objective on its own.
Use text and paper for early questions
If the question concerns an invitation, prepare the invitation itself. Ask the reader to explain what is expected, when they need to reply and what will happen next. A decorative interface may add nothing useful to that check.
Paper cards can support a discussion of sequence. Lay out the steps for joining a shift and ask where someone expects to find the requirements. Record questions and rearrangements instead of defending the original order.
The limitation is the simulated interaction. If a facilitator moves the cards and explains every step, you cannot conclude that the participant would independently understand a website. Note the help required rather than treating it as invisible support.
Add interaction when the answer depends on it
To observe where someone clicks and whether they can return to an earlier step, prepare connected screens. Testing data entry, error recovery or keyboard behaviour may require working elements that support those actions. A still image cannot demonstrate them.
Compare available behaviour rather than tool names:
| What to observe | What needs to work |
|---|---|
| Choosing a next step | Understandable links or buttons and transitions between relevant states |
| Correcting an error | Input, an error message and another attempt |
| Using a keyboard | Real controls, focus and access to the actions being examined |
Keep conclusions within the model’s scope. Testing one path does not cover every screen or way of interacting. Include the important limitations in your research notes rather than allowing visual polish to imply broader coverage.
Model a process when the question is not about a screen
To examine how coordinators pass on a request, act out who receives the message, what they check and whom they answer. The GOV.UK prototyping toolkit includes letters and role-play scenarios. A service model does not have to be an application.
For a question about the arrangement of objects, a simple physical model at a suitable scale may help. It can support discussion of placement without establishing the strength or safety of a future product. Material properties or real physical effort require a separate check.
Choose a format the participant can use. Larger text, another input method or their familiar device may be needed. Account for that when preparing the model rather than interpreting an inaccessible format as a problem with the participant.
Keep the model distinct from a live product
Before a session, check the relevant transitions and prepare fictional records. Participants should understand that the request is simulated and no real shift is being reserved. Do not collect genuine personal information merely to make a mock-up feel realistic.
Afterwards, keep the model version, question and observations together. Improving a prototype does not make it ready to launch; production implementation is separate work. GOV.UK explicitly cautions against copying prototype code into a live service without addressing production requirements.
If selecting a tool starts to eclipse the question, return to the criteria for choosing an application for a task. A useful format lets you obtain the intended observation with clear limits on what it can establish.
How was the article?
One tap helps us understand what you find useful
Discussion
Sign in with an email code to comment and like articles. We’ll bring you straight back here
Sign in to join the conversationComments: 0
It’s quiet here. Be the first to share your experience.