A team can test whether stakeholders share the same use-case definition by asking them to describe the use case independently and comparing the descriptions for substantive agreement. The check is whether they identify the same likely users, the same goal, and the same business value or context—not merely whether they use identical terminology.
What the definition should establish
The GOV.UK Service Manual says user research should begin by learning who the likely users are and what they are trying to do. NIST says the business value or context of business use should be clearly defined.
Those points provide a compact test for each stakeholder’s definition:
| Dimension | Question to answer | Sign of a shared definition |
|---|---|---|
| Likely users | Who is expected to use the product or service? | Stakeholders describe the same user population. |
| User goal | What are those users trying to do? | The intended task or outcome has the same meaning and scope. |
| Business value or context | What business value or context makes the use case relevant? | Stakeholders connect it to the same value purpose or operating context. |
Compatible answers do not need identical wording. They do need to describe the same users, goal, and business context without relying on assumptions that only one stakeholder understands.
How to run the test
-
Use the same prompt for everyone. Ask each stakeholder to identify the likely users, what those users are trying to do, and the business value or context of the use case.
-
Collect responses before discussion. Independent responses make differences visible before the group converges on a broad but vague description.
-
Compare each field separately. Place the responses side by side and classify each field as clear, ambiguous, or conflicting. This prevents strong agreement about users from concealing disagreement about the intended goal or business context.
-
Probe every discrepancy. Ask whether stakeholders are referring to different users, different tasks, or different contexts. A term may carry the same label while representing different ideas, so the team should test meaning rather than vocabulary alone.
-
Create and reconfirm one definition. Consolidate the agreed elements into a single statement, record unresolved issues, and ask each stakeholder to identify anything they believe the statement still leaves unclear.
A definition is not yet shared if stakeholders merely avoid disagreeing. Each person should be able to explain the final wording and flag any mismatch with their intended use case.
What the team must still confirm
This test measures alignment; it does not establish feasibility, data readiness, system performance, risk, or expected business value. Those remain separate validation questions.
The test also has no built-in numerical score. Before collecting responses, the team should define what it will treat as an acceptable difference in users, goals, or business context. Any unresolved difference should be recorded as an open assumption rather than smoothed over with general wording.
Agreement on the definition is therefore the starting point for further evaluation, not proof that the use case is ready for implementation.