The 69un.do journal

How to choose a prototype format for your question

Text, paper, interactive models or scenarios matched to the action you need to observe

Two people wearing augmented reality headsets examine a digital city model

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 observeWhat needs to work
Choosing a next stepUnderstandable links or buttons and transitions between relevant states
Correcting an errorInput, an error message and another attempt
Using a keyboardReal 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

Comments: 0

It’s quiet here. Be the first to share your experience.