Define an MVP app around one complete user task and the decision you need evidence to make. Separate the learning question from the feature list. Then specify a bounded prototype, observe suitable participants and decide whether to change, stop or extend the work. Do not describe an untested concept as validated demand.
What must the first version help someone do?
Write a sentence containing a person, a problem and a completed outcome. “A dispatcher can identify an unresolved collection and give its owner the information needed to act” is a proposed outcome. “Build a dashboard with filters” is an interface instruction. Prefer the outcome while investigating whether an app is the appropriate response.
The GOV.UK discovery guide starts with understanding the problem before committing to build a service. GOV.UK advises reframing a prescribed solution as a problem to be solved. The GOV.UK discovery guide provides a useful process reference; it is not a universal rulebook for commercial app delivery in Zambia.
Ask the team to identify which assumptions would make the proposed outcome irrelevant. Perhaps the person does not have the information being requested, or another team already owns the decision. Record those as questions to investigate. Do not turn an interviewer’s guess about a customer’s work into a requirement that appears to have been confirmed.
The guide recommends setting a clear discovery goal to define its scope. State what the first investigation can change. If the sponsor has already decided to purchase a particular product, record that constraint openly instead of presenting the exercise as an unrestricted product search.
Where should the MVP boundary sit?
Propose a complete, narrow journey rather than an arbitrary fraction of every feature. For a fictional equipment-hire enquiry, the initial journey might be “submit an equipment request and receive a clear acknowledgement of what happens next”. Live payment collection, fleet scheduling and customer identity verification would require separate decisions before inclusion.
This example is a proposed scope, not a tested service or a claim about software that Spout has deployed. Replace it with a real outcome from your investigation. Identify the information that enters the journey, the person responsible for its next step and the condition that counts as completion.
The discovery guidance asks teams to examine users, constraints and opportunities. Ask how connectivity, staff availability and existing records affect this specific journey. Do not assume that a mobile app must work offline, or that the intended users always have a particular device. Establish the requirement and then seek appropriate technical evidence.
The discovery guide says a team should not start building its service during discovery. Keep that distinction explicit in the project record. A research activity, an interactive prototype and a working release are different deliverables. If development starts, document that transition and what has authorised it; do not quietly call implementation “discovery” to avoid a scope decision.
Which experiment would change the next decision?
Use the original learning ledger below. Each row asks for evidence that can change a decision; none assumes a positive result. Its purpose is to connect work to uncertainty rather than award a validation badge for completing a meeting.
| Uncertainty | Proposed exercise | Record needed for the decision |
|---|---|---|
| Whether the outcome matches the user’s task | Ask a likely user to describe their current process | Their account, context and unresolved disagreement |
| Whether the prototype communicates the next step | Present a neutral task in a controlled session | Observed actions and any assistance given |
| Whether requested information is available | Ask where each sample field would come from | Known sources and missing information |
| Whether a handover has an owner | Walk a synthetic request through the proposed responsibility map | Named responsibility or unresolved ownership |
| Whether more development is justified | Review the findings against the initial question | Continue, change or stop decision with reasons |
Avoid invented numerical pass thresholds. If your organisation needs an acceptance threshold, agree it before the exercise and explain the basis for it. A convenient target chosen after seeing the result is poor evidence for the original decision.
Choose synthetic examples that expose the uncertainty. A missing equipment description or an unclear collection address may be useful for the fictional enquiry. Do not submit real requests to a business or send test messages to unrelated people just to make the prototype feel complete.
How should you observe the prototype?
GOV.UK defines moderated usability testing as watching participants attempt specific service tasks. That definition from GOV.UK’s usability-testing guidance concerns observed task attempts; a polished demonstration by the author is a different kind of evidence.
Its guidance recommends actual or likely service users as research participants. Write down why the selected participants are relevant to this task. Do not present colleagues who know the design as representative customers simply because they are easy to recruit. Where you only have internal feedback, label it as internal feedback.
The guidance says test tasks should set a clear goal for participants. It advises against tasks that reveal an answer or suggest how to complete them. For the fictional hire enquiry, ask the participant to request equipment for the stated situation. Do not tell them which button to select or explain the intended route before they try it.
The guidance recommends clear, neutral instructions when introducing a task. Record any help you provide, a point at which the participant stops and any question that reveals a mismatch between the interface and the task. Do not convert those observations into claims about conversion rates, commercial demand or production reliability that the exercise did not measure.
Keep an observation separate from an interpretation. “The participant asked who would call them” records a question. “Customers do not trust online enquiries” is a wider conclusion requiring further evidence. Use the narrower statement when deciding whether acknowledgement text or responsibility information needs to change.
What should happen after the first learning round?
Review the initial uncertainties before proposing another feature. Which questions now have evidence, which remain unanswered and which turned out to be irrelevant? Assign the next work to the decision it supports. A request to add account registration should explain whose task needs it, rather than rely on the claim that every professional app has accounts.
For the fictional enquiry prototype, one possible outcome is to clarify the acknowledgement and run another observation. Another is to stop app development because the problem concerns an unowned operational handover. Neither outcome has occurred here. The value of the ledger is that it allows the project to record either conclusion honestly.
Prepare a handover containing the current scope, prototype version, synthetic scenarios, observations, assistance given and next decision. Identify any security, accessibility or external integration assessment still required before a working release. A useful MVP learning record should make those boundaries visible instead of concealing them behind a broad “ready” label.
For implementation context, read web development and the separate mobile-app planning guide. Discuss your requirements with Spout by bringing the user outcome and the uncertainties you need to resolve.
By Spout Team. AI-assisted article authored directly with Codex from the cited primary guidance. The learning ledger and fictional hire example are proposed editorial exercises, not completed research, tested software or a promise of business results. Retained sources preserve their original retrieval dates.