An AI use-case brief should identify who the likely users are, what they are trying to do, and what business value or context makes the use case relevant. GOV.UK Service Manual frames user research around likely users and their goals, while NIST AI RMF says the business value or context of business use should be clearly defined.
Those are the two sourced anchors, not an official template. A useful brief develops them into a clear problem definition while keeping assumptions, technical choices, and promised outcomes separate.
Identify the likely users
A brief should distinguish the intended user group from people who are merely affected by the proposed system. Broad labels such as “employees” or “customers” may not provide enough context to understand the need.
The user description should clarify:
- Who encounters the problem?
- What are they trying to accomplish?
- What do they do today?
- Which parts of their work are relevant to the proposed use case?
This follows the GOV.UK Service Manual’s focus on understanding likely users and what they are trying to do. It helps prevent a proposed AI capability from being defined before the underlying user need is understood.
State the user goal in task terms
The brief should describe the task or problem rather than lead with a technical feature. Readers need to understand what difficulty exists, where it occurs, and why it matters.
For example:
The user group needs to complete a specific task within a defined process because an existing situation creates a relevant problem.
A vague statement that the system will “improve productivity” does not explain the user, task, or business context. Nor does it establish that the proposed AI approach will produce that result.
Define the business value or context
NIST AI RMF highlights the need to define the business value or context of business use clearly. The brief should therefore explain:
- Which business process, decision, or activity is affected?
- Why is the user goal important in that setting?
- What outcome would represent value?
- Which constraints shape the use case?
- What is explicitly outside its scope?
Business value does not have to be reduced to a financial figure. It can concern the importance of a task, an operational constraint, or the consequences of addressing the problem. Any intended benefit should remain framed as a value hypothesis rather than a guaranteed outcome.
Separate facts, assumptions, and unknowns
A context brief becomes more useful when it makes the status of each statement visible. A reviewer should be able to distinguish among:
- Known context: supported user research, process information, or other verified material.
- Working assumptions: points that still need testing.
- Unknowns: information that has not yet been gathered.
- Scope boundaries: situations, users, or processes the use case will not cover.
This prevents an assumption from being mistaken for an established fact. It also leaves the team with clear questions to investigate rather than giving those questions a false appearance of certainty.
A practical brief structure
The following is an editorial template, not a requirement prescribed by either cited source:
- Likely users: Who has the need?
- User goal: What are they trying to do?
- Current situation: What happens today?
- Business value or context: Why does the task matter?
- Scope: Where does the use case begin and end?
- Evidence: What supports the problem definition?
- Assumptions and unknowns: What still requires confirmation?
- Evaluation question: How will the team assess whether the use case is useful in context?
How to check whether the context is clear
A reviewer can test the brief against a short set of questions:
| Context check | Question for the reviewer |
|---|---|
| Users | Can the likely user group be identified without assuming that everyone is a user? |
| Task | Is the user’s goal expressed independently of a proposed technical solution? |
| Value | Is the business value or operational context explained rather than asserted as a slogan? |
| Scope | Are the relevant boundaries and exclusions visible? |
| Evidence | Are verified facts separated from assumptions and unknowns? |
| Outcomes | Is any expected value framed for evaluation rather than promised in advance? |
If a material part of the answer depends on guesswork, that point should remain marked as unknown until it is checked.
What still requires confirmation
The two cited statements do not establish whether a particular AI use case is feasible, approved, adequately resourced, or likely to deliver a specified result. The team must still confirm matters such as:
- The actual user need through appropriate research.
- The current workflow and its constraints.
- The availability, quality, access, and permissions of relevant data.
- Applicable legal, regulatory, security, privacy, and risk controls.
- Technical feasibility and the method for evaluating performance.
- Resource requirements, ownership, dependencies, and timing.
A strong use-case brief does not settle those questions by itself. It makes the questions explicit, separates the supported context from assumptions, and gives the team a basis for deciding what must be confirmed next.