Start with an outcome someone needs
A project often begins with a proposed solution: an app for customers, a marketplace, or a redesigned website. Rewrite that idea as a task: who needs to achieve what, in which situation, and what currently prevents them? GOV.UK’s discovery guidance recommends understanding the problem before committing to a service.
Consider a hypothetical Baghdad repair business. Customers repeatedly call to check whether a technician is available. The desired outcome might be a confirmed appointment without repeated calls. That does not yet determine whether the answer is a booking page, a better internal schedule, or a mobile app. Write down the outcome and keep those options open.
Collect evidence from current behaviour
Speak with people who actually encounter the problem, including staff who handle exceptions. GOV.UK’s research guidance includes examining the current journey and involving people with different abilities and support needs. Ask participants to describe a recent incident, then, with permission, show how they dealt with it.
Useful prompts include: What started the task? Which information was missing? When did you ask someone for help? What happened after you submitted the request? Record concrete steps and consequences. A compliment about your idea is weaker evidence than a repeated difficulty. For an Arabic, English, and Sorani service, test the task in the languages people use; language preference should not be guessed from location.
Test the assumptions that could invalidate the project
GOV.UK recommends turning unsupported assumptions into research questions; its alpha guidance uses prototypes to explore risky parts of a solution. Apply that approach to your own decision, without copying government delivery timelines.
List assumptions such as customers accepting a booking deposit, staff keeping availability current, or an existing system exposing usable data. Rank them by the damage caused if they are false. A clickable booking prototype can test comprehension. A supervised manual booking trial can reveal staff workload. A technical experiment can test an integration. These are different tests: a usable prototype does not prove demand, and an integration demo does not prove that customers will return.
Scope one complete journey for the first release
Define your minimum viable product, or MVP, as the smallest release that can deliver the chosen outcome and answer a business question. For the repair example, that could mean choosing a service, requesting a time, receiving confirmation, and changing or cancelling the request. Include the staff action that makes confirmation real.
Separate essentials, later improvements, and explicit exclusions. A loyalty programme might wait; clear error messages and protection of customer data should be part of the relevant work. If confirmation remains manual, say so in the interface and agree who handles it. Reducing scope means serving fewer needs well, while making the limits understandable.
Prepare a brief that supports an honest estimate
A useful brief exposes decisions and uncertainties. It does not need to predict every screen. Use this numbered checklist before asking a development partner for a proposal:
- 1. Outcome and audience: identify the primary user, their task, and the evidence that the problem matters.
- 2. First-release journey: describe entry, completion, failure, cancellation, and the staff workflow.
- 3. Content and languages: name who supplies, translates, checks, and updates text and images.
- 4. Data and integrations: list existing systems, access owners, required fields, and unresolved dependencies.
- 5. Constraints: state budget boundaries, the reason for any deadline, supported devices, and accessibility needs.
- 6. Acceptance and ownership: define what must be demonstrated, who approves it, and who operates the service after handover.
Include the work around the software
A booking form can work perfectly while the service fails because nobody reads the requests. Walk through an ordinary day and a difficult day: a staff member is absent, a customer enters the wrong phone number, or an external service becomes unavailable. Assign responsibility for each case before launch.
Also agree who controls the domain, hosting, source repository, analytics, and third-party accounts. Identify the recurring work: content updates, access reviews, backups and recovery checks, support, and technical maintenance. Ask proposals to separate initial delivery from ongoing operations and to name assumptions behind estimates. The cheaper first invoice is not enough information to compare two approaches.
Decide what launch should teach you
GOV.UK’s benefits guidance recommends establishing a baseline before assessing improvement. For your project, record the current result where possible, then choose a small set of measures tied to the outcome.
For the repair example, track completed appointment requests, confirmed appointments, time to confirmation, and requests needing staff correction. Define each measure: a submitted form is not necessarily a confirmed booking. Review abandonment alongside interviews or support feedback so the numbers have context. Avoid collecting personal data merely because an analytics tool allows it.
Choose a review date, an owner, and a decision rule before launch. Evidence may justify improving a confusing step, expanding the service, keeping a manual process, or pausing further development. Traffic alone cannot tell you which choice is right.
Your next step
Before commissioning development, bring a problem statement, research notes, a bounded first-release journey, and a measurement plan. Those materials give you and your software partner a concrete basis for deciding what to build, what to test first, and what success would mean.