THE SHORT ANSWER
Explain the problem, affected user and desired outcome before prescribing a solution. Break work into small testable slices, label priorities, provide examples and constraints, and agree on acceptance criteria. When tradeoffs appear, ask what changes in user value, risk, time and future maintenance.
Bring a decision-ready brief
| Input | Useful form | Weak form |
|---|---|---|
| Problem | People abandon registration when payment status is unclear | Build an Uber-like app |
| Outcome | A registrant knows whether a place is confirmed | Make it seamless |
| Priority | Confirmation and recovery are required; referrals can wait | Everything is urgent |
| Example | A duplicate payment callback must not create a second registration | Handle edge cases |
| Acceptance | A successful payment produces one confirmed registration and receipt | It works |
Evidence & context: GOV.UK Service Manual · GOV.UK Service Manual
Discuss small, observable slices
A useful slice travels far enough through the system to produce a testable user result. A registration slice might show one program, accept valid details, create one record and display a confirmation. Later slices can add payment recovery, administration and reporting.
Small slices expose assumptions earlier and make progress visible without pretending the whole product is complete.
Ask for the consequence of each tradeoff
- Which user outcome changes?
- Which risk is accepted or reduced?
- What becomes harder to change later?
- What ongoing service or maintenance is added?
- What can be measured or tested before deciding?
Scope changes are normal. Make their effect on time, quality and other commitments explicit before accepting them.
Report behavior, context and impact
For a defect, record what you attempted, what happened, what you expected, the environment, whether it repeats and the user impact. Screenshots can help, but reproducible steps and affected data make diagnosis faster.
Review work against the agreed product requirement and testing plan, then update both when the decision changes.
Evidence & context: GOV.UK Service Manual
Sources & further reading
- Learning about users and their needs
GOV.UK Service Manual. Public-service design guidance linking user needs to stories, acceptance criteria and continued research. Its process should be adapted to the product and risk context.
- Agile tools and techniques
GOV.UK Service Manual. Practical guidance on user stories, prioritized backlogs and collaborative delivery. User stories support discussion; they do not replace design and technical analysis.
- Quality assurance: testing your service regularly
GOV.UK Service Manual. Government guidance on usability, functional, performance, security, accessibility and continuous testing. It does not prescribe one universal test suite.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗