Test a prototype before committing to implementation

A clickable prototype can make a proposed service feel complete before its operating rules or technical foundations are clear. Use that apparent simplicity to test understanding, not to imply readiness. The decision is whether the evidence justifies the next investment, which may be another test rather than immediate implementation.

Choose the question and the appropriate model

Identify the uncertainty that could change the product decision. Can users identify the correct request type? Do they understand what approval means? A paper model may answer a terminology question. A more interactive prototype may be needed to examine a multi-step correction journey.

GOV.UK describes moderated usability testing as observing participants attempt specific tasks.[3] Recruit actual or likely users whose circumstances match the question. Include relevant accessibility needs rather than assuming internal reviewers represent the people who will use the service.

Give a goal without teaching the route

Write a task in the participant’s language without repeating labels that reveal where to click. GOV.UK recommends clear, neutral task instructions and mostly watching and listening.[3] Ask participants to explain their thoughts, but avoid correcting each hesitation as it occurs.

Record the starting condition, actions, assistance, and result. Distinguish a participant’s independent completion from completion after hints. If the model cannot support an action, note that limitation instead of recording a design failure or pretending the action worked.

Hypothetical example: finding a service visit

A hypothetical building services provider tests a portal for arranging visits. Participants must find the visit linked to a particular work request and propose another slot. The prototype includes similar addresses to test whether people can distinguish the correct location.

If a participant chooses the wrong property, the researcher asks what informed the choice. The team revises the identifying information and tests again. The session does not establish that live scheduling can prevent double booking or that external systems will exchange updates correctly.

Prepare a prototype-test checklist

Agree these checks before sessions begin so the team does not redefine success after watching the results.

• State the decision and the uncertainty the test addresses.
• Recruit users with relevant tasks, environments, and access needs.
• Prepare neutral tasks and realistic, non-sensitive test records.
• Define how observers record help, wrong turns, and unsupported actions.
• Separate findings from the technical assumptions still requiring investigation.

Know what a prototype cannot prove

GOV.UK technology guidance recommends prototypes to explore technological assumptions and check interfaces with other systems.[7] Choose technical experiments for those questions rather than relying on a screen demonstration. Interface usability and integration feasibility require different evidence.

A small test can reveal problems without estimating their prevalence across the whole customer base. Avoid projecting a session result into a guaranteed adoption rate. Report what changed, what remains uncertain, and whether to revise, investigate technically, or proceed with a bounded implementation.