Choosing a first change without defining improvement takes us back to counting tools. We can report features released or people logging in while still not knowing whether the problem has become smaller. Useful measurement begins with the intended outcome. It then asks which signals can reveal the difference in real work, and which parts of the experience numbers cannot yet show.
Separate activity, use and outcome
Imagine an organization trying to reduce follow-up about requests. This is a hypothetical example. ‘The status page was released’ describes team activity. ‘People viewed the page’ describes use. ‘People know what happens next without making another call’ describes the intended outcome. All three are useful, but they answer different questions. More page views could even indicate that people are still unable to find an answer.
GOV.UK’s guide to setting performance metrics moves from a service’s purpose to its intended benefit and then to a testable hypothesis. In our example: clarifying status and responsibility should reduce follow-up. That hypothesis makes choosing a measure more precise than starting with a ready-made dashboard.
Have a comparison point before changing things
Before implementation, understand the current situation. How long does it take to receive a clear answer? Which requests come back for correction? What do people call about? You do not have to measure everything first. A specific definition recorded consistently within a limited scope is more useful than a large set of incomparable numbers. State exactly where a duration begins and ends.
After the change, keep the same definition and explain the conditions of comparison. Workload, request types or staffing may have changed at the same time. A lower number alone does not prove that the tool caused the difference. If a suitable comparison is unavailable, state the limitation. An honest account of an uncertain effect is more useful for the next decision than an unsupported claim of certainty.
Improvement for one person can mean pressure for another
Look beyond the average. Simple requests may move faster while complicated cases remain in a queue. A user may enter less information while support staff have to gather it from several places. Alongside speed, examine repeated work, answer quality and whether people can continue their journey. A measure should lead to a better question, not just a reassuring chart.
The GOV.UK standard on defining success includes performance information from online and offline channels. In this example, phone calls and in-person visits are part of the experience, not events outside the system. Ignoring them could hide a problem that has simply moved between channels.
Connect a number to a conversation and a decision
Alongside the data, ask people to explain the new journey. If they still message a familiar colleague for reassurance, fewer recorded calls are not the whole story. That conversation does not replace the number; it helps explain it. Also identify who reviews a measure and what they can do when an unwelcome signal appears.
A simple measurement page can connect the goal, the change hypothesis, a main measure, a warning of unintended effects and a review point. Its purpose is not to award the team a score. It is to learn about the service. If the result is not as expected, revising or stopping the change must be possible. That knowledge prepares the way for responsible choices about data, automation and technology later in the path.