Start software prototyping with the decision you need to make, then build the smallest representation that can expose a wrong assumption. Give likely users a realistic task, record what they actually do and decide what changes. A convincing demonstration is useful only when its limitations and unanswered questions remain visible to the delivery team.
Which uncertainty deserves a prototype?
Choose a problem that could change whether or how you build. A business owner might be unsure whether customers understand a proposed service package, whether staff can identify the correct account or whether an existing system can supply required information. Write that uncertainty as a question before choosing screens or a prototyping tool.
GOV.UK describes alpha as trying different solutions to problems identified during discovery. Documentation. The source describes a UK government delivery process. Its phase names are a useful reference here, not a mandatory method or timetable for a Zambian business. This article adapts the experimental idea into an original assumption worksheet rather than claiming compliance with that process.
The alpha guidance recommends concentrating on the riskiest assumptions. Documentation. Put the consequence of being wrong beside the question. An assumption affecting the whole operating model deserves a different experiment from a preference about a button label. Ask who would need to change their decision if the proposed evidence contradicted the idea. If nobody can answer, tighten the question before building.
The alpha guidance says a prototype need not cover the entire wider user journey. Documentation. Draw the boundary of the experiment explicitly. A clickable quotation journey might test whether customers distinguish an enquiry from an accepted order without implementing billing. A technical experiment might test an import using synthetic records without creating a public website. Neither exercise should be described as proving the complete business service.
What should you build and what should stay unfinished?
The alpha guidance says online prototypes should be only complex enough to test ideas. Documentation. Select the representation that addresses the uncertainty: a sketch, a clickable sequence, a data transformation or a small integration experiment. Record which parts are simulated. A screen that pretends to save a record should be labelled as such in the research brief and in the handover.
The alpha guidance explicitly anticipates discarding prototype code. Documentation. Keep exploratory code separate from the proposed production implementation. Before any reuse, ask the delivery team to assess security, accessibility, error handling and maintainability independently. This is a recommendation for interpreting the experiment, not a claim that the prototype already satisfies those requirements.
Avoid building a complete account system merely to discover whether the service labels make sense. Equally, do not substitute attractive static screens for an uncertainty about whether a required data exchange works. Match the artefact to the question and resist expanding it to impress stakeholders with unrelated functionality.
An original assumption-to-decision worksheet
Use this practical checklist as a blank working document. It records a decision, an experiment and the limits on interpreting the result. The examples below are prompts for designing work, not observations from completed research.
| Field | Entry to prepare | What the reviewer should challenge |
|---|---|---|
| Assumption | What must be true for the proposed service to work | Is this a belief or something already established? |
| Consequence | What changes if the assumption is wrong | Does the uncertainty matter to the decision? |
| Representation | Sketch, clickable journey or technical experiment | Can this artefact expose the relevant failure? |
| Task | Goal given to the participant | Does the wording lead them towards the answer? |
| Observation | Actions, questions and breakdowns actually seen | Is interpretation being presented as a quotation? |
| Limitation | Simulated steps and missing conditions | What remains untested? |
| Decision | Change, investigate, proceed or stop | Who owns the next action and its rationale? |
Add a reference to the precise prototype version used. If the interface changes between sessions, keep the observation attached to its version. Do not combine outcomes from different designs and report them as though everyone attempted the same task.
Keep an observation and an inference in separate columns in the working copy. For example, a participant returning to the service list is an action; believing that the package names caused confusion is an interpretation requiring examination. Preserve both so the team can challenge the inference without losing the underlying event.
How do you learn from someone using it?
GOV.UK defines moderated usability testing as observing participants attempting specified tasks. Documentation. The method requires an actual session before you can claim results. Until then, call the document a research plan or task script. A team member clicking through their own design can help expose defects, but should not be presented as evidence about likely customers.
The usability guidance recommends recruiting actual or likely users. Documentation. Specify the relevant experience or circumstances in the recruitment brief. For a staff-facing process, include the people expected to perform it, rather than only managers who approve expenditure. Explain what you need to learn without treating a small convenience group as representative of a whole market.
The usability guidance says tasks should avoid revealing the answer. Documentation. Instead of instructing someone to click the package comparison tab, give them a service need and ask them to work out what to request. Let their route reveal whether the proposed information and controls support that goal. Agree in advance how the researcher will respond if the participant becomes stuck.
The usability guidance recommends a discussion guide to keep task presentation consistent. Documentation. The usability guidance recommends clear, neutral task instructions. Documentation. Keep the facilitator’s intervention visible in the observation record. If somebody completes a task only after receiving a hint, record the hint rather than counting that completion as independent success. Do not invent a pass percentage or population-wide conclusion from the exercise.
Hypothetical example: an enquiry mistaken for an order
Imagine a proposed business website offers several service packages and an action labelled confirm. The team wants to know whether visitors understand that the action sends a request for discussion rather than placing an order. This is a hypothetical teaching case; no user session or Spout client result is being reported.
Prepare a version with the proposed labels and ask a likely user how they would request the service they need. Observe the point at which they believe a commitment has been made. Ask a neutral follow-up about what they expect to happen next. Keep the question separate from any explanation that would teach them the intended answer.
If a participant’s understanding differs from the intended process, preserve the observed words and revise the information or action. Run the changed version as a new experiment. Do not assume that replacing a label resolves the entire commercial journey; the confirmation message, follow-up and written scope may still need examination.
When can the team make a delivery decision?
Close each experiment with the decision owner and the remaining uncertainty. A usable output might be a revised service definition, a rejected integration approach or a requirement for further research. Avoid a general declaration that the software is validated when only a small interaction was examined.
For delivery, hand over the prototype version, task script, observations, interpretation and unresolved questions together. Include any parts intentionally omitted so that they become explicit delivery work. A prototype should clarify a commitment to build, rather than quietly expanding that commitment through an impressive demonstration.
Keep broader market validation with the online-business planning guide. For the website implementation brief, see web development and get started with the decision you need evidence to support. These links invite a scope discussion without asserting that Spout has already tested your idea.
Spout Team — AI-assisted drafting by Codex from the cited primary documents. No independent human or professional review, completed product test or client result is claimed.