A team should define three linked elements: the user whose problem matters, the task that user is trying to complete, and the decision boundary separating what the proposed system may do from what remains outside its role. The user and task should be described without relying on technology terminology. The boundary should state who has decision control, what actions are permitted, and when the system must stop or hand the matter over.
Start with the user’s problem
The GOV.UK Service Manual advises focusing on the user’s problem rather than possible solutions. Its user-research guidance starts by asking who the likely users are and what they are trying to do.
A useful starting statement is:
[Likely user] is trying to [complete a task] because [problem] in [situation].
This statement should remain understandable without mentioning a model, interface, or vendor. If the description only makes sense after naming a proposed technology, the team has probably started with a solution rather than a clearly framed need.
The team should then check whether the identified characteristics actually affect the user’s problem, access to the task, or required output. Broad labels that do not change any of those elements are unlikely to help the team make a product decision.
Define the task as a concrete action
The task is the work the user is trying to complete, not a broad aspiration such as improving efficiency or reducing effort. It should identify the action or output needed in the relevant situation.
A task statement can use this structure:
When [situation], [user] needs to [action or output] using [available information], excluding [out-of-scope activity].
The team should be able to answer several practical questions:
- What starts the task?
- What information is available?
- What does the user need as an output?
- What condition indicates that the task is complete?
- Which related activities are outside the task?
A task becomes easier to evaluate when the expected output and completion condition are visible. If reviewers cannot tell what the task produces, they are unlikely to agree on whether a proposed system performs it correctly.
Make the decision boundary explicit
The decision boundary prevents a user need from expanding into an undefined request for automation. It identifies the specific decision or action involved, the system’s permitted role, and the point at which control passes elsewhere.
| Boundary question | What the team should state |
|---|---|
| What decision is involved? | The specific choice the task is intended to support |
| What may the system do? | The permitted action, such as presenting information, drafting an output, recommending an option, or applying an explicit rule |
| Who has final control? | The person or defined process that owns the decision |
| What is excluded? | Actions, data, or situations outside the use case |
| When does the system stop? | Conditions that require clarification, review, or escalation |
A boundary statement can follow this pattern:
For [task], the system may [permitted action] using [inputs]. [Decision owner] retains [final control]. The system must not perform [excluded action]; cases involving [stop condition] require [handoff or escalation].
The system’s role should not be left implied. A process that retrieves information has a different boundary from one that recommends a choice or generates a draft. The appropriate role depends on the task and the team’s validation, rather than on the technology being considered.
Check that the three elements fit together
The framing is coherent when each element answers a distinct question:
- User: Whose problem is being addressed?
- Task: What is that user trying to do?
- Decision boundary: What decision or action is being supported, and where does the system’s role end?
The team should also ask whether the task actually requires the proposed capability. A user problem can sometimes be addressed by changing a process, improving an interface, or removing work; it does not automatically justify an AI system. This check keeps the use case open to alternatives before technology selection begins.
What the team must still confirm
The cited guidance provides a starting point, not evidence that a particular use case is valid. Before evaluating models or vendors, the team still needs to confirm:
- Who the likely users are and what they are actually trying to do.
- Whether the task, expected output, and completion conditions are clear.
- Who holds decision control and what the system is permitted to do.
- When the system must stop, request review, or escalate.
- What evidence would show that the task and boundary are working as intended.
- Any applicable organizational, legal, privacy, security, or safety requirements.
Until those points are validated, the user–task–decision-boundary statement is a hypothesis for further research, not a confirmed product requirement.