Describe the problem and the people affected
Describe what someone is trying to do, what gets in the way, and how the team will know the process improved. Talk with the people doing the work and receiving its result. Review records, forms, messages, and exceptions. Explain the idea in the language of the work, not only as features.
The GOV.UK Service Manual recommends a clear vision and user needs for agile delivery. For a private project, write a one-sentence outcome, name the users, and identify who decides scope and policy.
Synthetic example: a small services company copies email enquiries into a spreadsheet. Its need is to capture requests, show ownership, and know when a reply is due. A first release might address intake, ownership, and status.
Map the current and desired workflow
Map the user's current steps, who performs them, which system holds the data, where details are retyped, and what happens when information is missing. Mark decisions. This can expose unclear ownership, duplicate data, or an unsettled policy as well as a missing tool.
Draw the simplest desired route in ordinary words, such as 'the coordinator reviews the request.' Add important exceptions, then revise the model as users try a prototype.
- Name the user, trigger, required information, outcome, and process owner.
- Record the source of each important fact and who can change it.
- Mark missing information, approvals, privacy needs, and failure cases.
- Agree on what the first release will leave for a later stage.
Write requirements people can review
Write short requirements that describe visible behavior. For example: 'A coordinator can see a request's owner and status.' Add a way to verify each one. Separate must-haves from later ideas, and include accessibility, roles, exports, history, and integration failures.
Record assumptions, open questions, the decision owner, and a due date. Involve privacy, security, or policy reviewers early when needed. Do not turn a guess into a fixed requirement.
Choose measures tied to the outcome, such as incomplete information, handoff waits, duplicates, or repeated questions. Set a baseline and avoid collecting unnecessary data.
Keep the requirements small enough to review with users. A coordinator, operator, and decision owner may all need different details, so check the first version with each role. Their feedback can reveal whether a status, permission, or approval step is missing before the team depends on it.
Prototype, test, and narrow the first release
Make the smallest demonstration that lets a user try the key step. A sketch, mockup, or working slice can reveal confusing labels before a larger build. Observe a realistic task, note pauses, and revise the workflow.
Test expected use and failure: different roles, missing or duplicate data, small screens, and unavailable integrations. Define acceptance evidence. If AI is involved, test uncertain and incorrect responses and how people continue.
GOV.UK planning guidance describes iterative delivery and review. Even a small release needs an owner, support route, appropriate security review, and a way to correct issues.
Plan for ownership after launch
Before development, assign owners for software, accounts, data, documentation, support, and changes. Agree how to receive releases, report problems, and pause or roll back changes. Include operators in reviews.
Keep a short log of the goal, first-release boundary, assumptions, and tradeoffs. Review progress against the outcome. When new requests arrive, check whether they solve an observed need or belong later.
After the first release, compare results with the baseline and ask what remains difficult. Improve, expand, or stop based on what users learned. Keep the software understandable to its owners.
The plan should identify a person who accepts the first release and a person who can authorize follow-up changes. If those are different roles, describe how decisions move between them so unresolved requests do not become hidden work.
- Name the long-term owner for access, support, and changes.
- Set acceptance criteria and a review date for the first release.
- Keep a manual fallback for key work while the new process is introduced.