Teams can measure adoption by separating observable use from evidence that the intended users benefit. Usage shows that a capability was reached, invoked, or repeated; it does not by itself establish meaningful adoption or whether the service met the needs it was designed around. The GOV.UK Service Manual therefore advises combining performance metrics with user research rather than interpreting usage figures in isolation.
Adoption and value answer different questions
Usage, adoption, and value should not be treated as interchangeable:
| Signal | What it indicates | What remains unproven |
|---|---|---|
| A capability was invoked | Activity occurred | Whether intended users adopted it |
| Output was accepted or a task continued | The interaction may have supported adoption | Whether the user need was met |
| A workflow was completed | The capability participated in a successful task | Whether the result was useful relative to an alternative |
| Users report a benefit | Research provides evidence of perceived value | Whether the benefit is consistent or caused by the capability |
This distinction matters because a high-volume event can still represent rejected output, repeated retries, or activity that does not support the intended workflow. Conversely, limited usage may still be meaningful if the capability serves a narrow need and works reliably for that group.
How to check the interpretation
A team can establish a clearer adoption measure through the following sequence:
-
State the user need. The GOV.UK Service Manual says metrics should reflect the user needs a service is designed to meet. A count without that context cannot show whether the metric is relevant.
-
Define the intended adoption behavior. The team should identify who is expected to use the capability, in which situation, and what behavior would indicate genuine adoption rather than accidental exposure.
-
Add context to usage metrics. Relevant context includes the user group, workflow stage, task outcome, and what happened after invocation. These details help distinguish meaningful use from activity that stalls or fails.
-
Measure the user outcome separately. Completion, quality, and research signals can show whether the intended result occurred. They should complement rather than be replaced by usage totals.
-
Combine metrics with user research. The GOV.UK Service Manual advises using both performance metrics and user research, then iterating based on insight from each. User research can reveal whether users understood the capability, trusted the result, or incorporated it into their work.
-
Check alternative explanations. Increased use does not necessarily mean increased value. It could reflect a new interface, more eligible users, retries, test activity, or a change in how the capability is exposed.
The resulting evidence chain is stronger than a single adoption percentage: user need → intended behavior → contextual usage → task outcome → research evidence → alternative-explanation check.
What teams must still confirm
The cited guidance does not establish a universal adoption formula, threshold, reporting period, or causal method for AI use cases. Each team must confirm those elements against its own service context, current internal definitions, and research.
Before drawing a value conclusion, the team still needs to establish:
- the intended users and relevant workflow;
- what counts as successful adoption;
- whether the observed outcome met the defined user need;
- which alternative explanations remain plausible;
- whether the evidence supports a local finding, a segment-level conclusion, or a broader claim.
Usage can establish that activity occurred. Need-aligned metrics and user research are needed to determine whether that activity represents adoption—and still more evidence is required before calling it value.