Choose an outcome and a group of users
Imagine a fictional company lending equipment to its departments. Requests currently arrive by email, and a coordinator updates a spreadsheet. The initial objective could be making requests and confirmations visible to one department, from asking for equipment through to returning it.
That choice defines the users and their task. Payments, a public catalogue and multiple locations can wait. If the real problem is immediate availability, collecting requests will not meet it. Change the scope before commissioning development.
Prioritise through practical questions
For every proposed feature, ask which step it enables, for whom and what happens without it. The table helps distinguish a first-cycle requirement from an interesting idea. Priority follows the answers rather than the name of a technology.
| Decision | Equipment-loan example |
|---|---|
| Needed for the first delivery | Request, availability check, confirmation and a visible record of return. |
| Needed to use that workflow | Appropriate access, verified saving and understandable errors. |
| Can wait | An alternative calendar view and personal appearance preferences. |
| Needs an early proof | A connection to the system holding actual availability. |
Agree where a manual step can remain
For the initial example, the coordinator might check availability in the spreadsheet and confirm the loan in the app. This can work when the initial value is organising the work and making its status visible. Document that manual step, its owner and how information is updated.
If users need immediate confirmation, that manual step may make the solution unsuitable. Distinguish an instant answer from a request awaiting review. An agreed manual task narrows development only when it preserves the required outcome. Document the responsibility before delivery.
Test the assumption that could stop the project
The GOV.UK Service Manual recommends using prototypes to test the riskiest assumptions before proceeding. Applied to this example, if the app must obtain availability from another system, request a small, focused demonstration of that capability, using authorised access and suitable test data.
If the uncertainty concerns usability, let prospective requesters and coordinators try the sequence. Observe where they stop and which information they look for. The test should support an explicit decision: continue with the assumption, change it or reject it. Compare the observed behaviour with the initial goal.
Separate correct delivery from observed usefulness
Acceptance testing checks that the app does what was agreed. Evaluation during use checks whether that solution helps with the chosen job. These are different questions: a feature may meet the specification and still see little use.
For acceptance, test a loan from request to return, together with a case where equipment is unavailable. During initial use, record completed requests, steps repeated outside the app and points where people need assistance. Agree the observation period, owner and conditions for deciding what happens next.
End the brief with four decisions
Bring this summary to an initial discussion with Ospivia. It helps compare a proposal with the objective and assess new ideas. Keep deferred features separately, with a reason for revisiting each one.
- The complete job and the group using the first version.
- The included features and accepted manual steps.
- The assumption to test before investing in the complete build.
- The acceptance criteria and observations that will guide the next version.
Explore an example
Explore ServiceBot to see a request move through defined states. The demo uses synthetic data and shows a limited workflow to compare with the one you want to build.
Explore a bounded workflow ↗Prepare your project brief
A reusable text template: objectives, users, features, materials and acceptance checks. Download it without registration and edit it with your team.
Download the project brief (.txt) ↓Technical references
Published by Ospivia Studio, prepared with AI assistance and checked against the linked technical sources. Examples are illustrative and are not customer results.