Service Performance is a tool that GDS is working on that aims to give people standardised high-level metrics about all government services in one place. Service Performance is currently in private beta and has been developed following a rediscovery by the Performance Platform team.
On the team, we’ve been working to identify user personas for Service Performance. From this work, we’ve identified a primary user persona – ‘the Conductor’.
Conductors are people who need to have a high-level overview of how services and organisations are performing across government. For example, they could be people who are responsible for a number of services, or people who have a strategic decision-making role.
During our discovery and alpha stages, we carried out research with these users to understand more about their needs. To help us do this, we set up a process for continually refining these user needs, based on what we learned.
Here are the steps we followed:
1. Agree what makes a good user need
We wanted to reach a common understanding of what ‘user need’ meant to our team at this stage of the project. To do this, we ran a team workshop.
We each wrote our understanding of what user needs mean on sticky notes. We referred back to Service Manual guidance and other reading. Then we grouped them to find the common points.
We agreed that a user need should be:
- concise and descriptive
- clear about the user’s underlying motivations
- unlikely to change
- something the team can use to make actionable decisions
- distinct from other needs
- organised in a clear hierarchy
- written in a consistent format
We also agreed that a user need should not be:
- something that might lead to a particular solution, feature, requirement or technology
- open to interpretation
- narrow enough to limit possibilities
We also settled on 3 different types of user need. These are inspired by the 3 types of user need that the GOV.UK Verify team uses.
The 3 types are:
- explicit needs: derived from how our users describe what they are trying to do
- implicit needs: those that are not expressed and that users are sometimes not aware of, but that are evident from our observation
- created needs: where a user has to do something because it is required by the service
We decided that when we recorded user needs, we should categorise them by these types. This would help us to understand where these needs come from.
2. Write user needs in a clear and consistent way
Using our agreed criteria we re-evaluated each of our existing user needs descriptions to produce an improved set of needs.
While we were rewriting the needs, we spent time to make sure each one was as clear as possible.
We listed all the needs in one spreadsheet and we followed the Service Manual guidance to create a consistent format. Our user needs looked like this: ‘As a Conductor (our primary persona), I need an overview of services across government in order to know where the focus should be.’
3. Organise user needs into a hierarchy
To make it easier to see if and how the needs related to each other, we organised them in a hierarchy.
We started by grouping the needs into clusters according to their relationship. Through doing this, we eventually grouped them into 3 levels, based on how specific the need was for our primary persona:
- high-level needs – for example: ‘I need to understand the data so that I don’t use it incorrectly’
- needs – for example: ‘I need to trust the data so I can defend my decision’
- detailed needs – for example: ‘I need to know how reliable the data is, so that I can provide caveat if needed’
Using these different levels of granularity, we could have needs that were more specific and easier to work with, while also maintaining an understanding of the higher-level needs.
4. Make a user needs board
As a team, we thought about different ways of presenting the needs within their hierarchy.
We had to ensure that our team would keep looking at them and that we could keep working on them.
We also needed to access the needs quickly, but have the ability to dig into the details if necessary. After trying out a few different ways of showing the needs, we settled on a Trello board, as it gave us this flexibility.
We also documented the status of solutions and the technical feasibility we explored for specific needs. This helped show where we were in terms of meeting the needs of our users and also demonstrated how decisions are made based on user research.
5. Keep iterating our descriptions of user needs
As we develop our tool in private beta, we will iterate our board to reflect our increasing understanding of our users. It's a great way to track things that we learn and demonstrate how our product is moving in the right direction.
We will continue to use it as we move into public beta and as our understanding of our users evolves further, to ensure that we always meet their needs.
Follow Tingting, Chris and Katie on Twitter and don't forget to sign up for email alerts.
1 comment
Comment by Nadia posted on
So, you can then create a 3x3 matrix of explicit/implicit/created VS high-level/needs/detailed needs?