How complete your prototype needs to be depends on the question you want the study to answer. It does not require every future feature, but the planned flow must allow the relevant decision. Otherwise, after the first click you are observing a dead end rather than the intended task.

What should you be able to say after the study?

Clarifying the study goal before choosing a prototyping tool helps determine the work needed. Understanding a service label requires different content from comparing two offers or following a long workflow. That tells you which views and states to prepare.

The GOV.UK alpha-phase guide describes using prototypes to investigate uncertain assumptions. Review the required flow rather than a completion percentage: which information and choices must a participant encounter for this task?

If you want to test whether prospects can distinguish analysis from implementation, for instance, you need accessible offer pages with realistic descriptions and a plausible next step. Payment processing does not yet need to be built for that question. But if the descriptions only say “Package A” and “Package B”, the material needed for the decision is missing.

Include the relevant alternative

A linear click-through can make a task appear easy. If every interactive area leads to the right next screen, participants have little real choice. Investigating selection requires a plausible alternative and a way back.

Check the prototype against the planned tasks:

  • Is the necessary information visible, with realistic content length?
  • Can people make and revise the relevant decisions?
  • Is the end state clear without the facilitator explaining it?
  • Is it clear which actions are simulated and what they would do?

Not every secondary function needs to work. If someone tries to open an unfinished area, note why they looked there. Do not redirect them in a way that erases their original approach from the findings.

Separate design detail from technical evidence

A click-through prototype can investigate sequence and wording. It does not automatically establish that keyboard interaction, loading behaviour or actual server errors will work. Questions about those aspects require a suitable technical version.

An early sketch may, in turn, be enough to discuss how a flow is divided. Participants then need to understand what is a placeholder. Empty space should not accidentally be evaluated as a finished content decision. Record the tested version and date.

A walkthrough without directions to the intended click areas shows whether the setup is ready. Include a plausible detour, because participants may not follow your preferred route. If the task only works with spoken guidance, the setup or research question still needs adjustment.

For each test goal, record what works in the prototype, what is simulated and where the limits remain. That overview gives you a basis for planning usability testing. If the business options are still unclear, UX decision support should first establish what needs to be represented for comparison.