People use government services to get many kinds of thing done in their lives. For example, learning to drive, running a business, or becoming a childminder. To achieve these kinds of goals, users are required to use multiple government services, run by different departments and agencies.
Across the UK government, service communities are trying to optimize how these related services are delivered. Service communities are semi-formal, cross-departmental groups of people with different skills. Each service community focuses on a particular service area.
Example: starting a business
The service community for starting a business involves people from a range of different roles including policy, strategy, design, and administration. It has representatives from government departments such as
- Her Majesty’s Revenue and Customs (HMRC, which deals with tax)
- The Department of Work and Pensions
- The Department of Business, Energy & Industrial Strategy (BEIS)
- The Department for Education
- Companies House (which deals with making company information public)
- The Department for International Trade
- The Pensions Regulator (Wynne-Morgan and Harmer, 2018)
The process of setting up a business requires users to interact with each of these government departments through various services. The idea of the service community is for people across these organisations to work together to improve the end-to-end experience for someone setting up a business.
Sharing research about one user across services
The members of a service community come together to share knowledge and research, to collaborate, and to break down silos to try and produce better end-to-end services for the user. Sharing research and other potentially sensitive information across organisational boundaries isn’t as simple as it may sound. It takes collaboration and consensus to figure out the best way to do this. I relearnt through working on this that you won’t always get it right the first time and that it is okay to fail and to talk about that failure. It’s not an end but a step in the learning process.
Government Digital Service (GDS), where I am Head of User Research and Analysis, work to create the environment and provide the tools for these communities to run. We’re still working on what these things are and how they work. One of the biggest things identified early on while setting up a community is that being able to share research about the same users using different services is a top priority. Without user research, we can’t know if we’re providing the users with what they need.
We had two big questions:
- How do we get a shared understanding of users and their needs across an end-to-end service?
- How can we share findings across organisational boundaries?
The initial hypotheses were:
- As the same people are using the different services at each phase, end-to-end service personas and user needs are useful. Personas are usually created for a specific service but an end-to-end service persona would be a persona for all the services that the user needs to interact with to achieve their goal. For example, starting a business.
- We need to share findings across the community. But not at the level of detail shared internally. For example, a summary of findings and insights rather than anonymised transcripts. Sharing the latter across departmental boundaries would almost be making it public, raising GDPR issues.
Research sharing workshop
Using these assumptions, we ran a workshop with people from the ‘starting-and-running-a-business community.’ A mixture of user researchers, customer insight people, products managers, and digital directors from eight different agencies and central government departments.
The plan was to start building a shared understanding of what research is happening in the community. We also wanted to include a unified view of personas for each phase of starting and running a business that makes up the end-to-end service. We were going to do this by
- doing a show and tell summarising the service/product, primary personas, and recent pieces of research.
- mapping out what elements/components of a persona would be useful.
- looking at common behaviours and needs of personas for each phase and sketching some merged personas.
- brainstorming what metadata would be useful when sharing research.
What we were hoping to achieve
It was a good idea. But we also knew it was very ambitious and that we wouldn’t solve everything with one workshop.
The workshop didn’t go according to plan. We didn’t have quite the right people in the room. And we were asking people to context switch, which is difficult. You need to zoom out of thinking about one transactional service and instead think about the end-to-end service: from when a user starts a task to achieve their goal to when they have finished all their tasks and achieved their goal (or got some other outcome). We hadn’t done enough groundwork to allow that to happen.
The show and tell revealed that we need to share insight and talk to each other about our work. But we weren’t able to create a merged persona or identify any end-to-end user needs.
What we actually achieved
Instead, we identified the overlaps of who was working on what. So people learned who to talk to about research in certain areas of interest.
We also discussed the concerns that everyone had about sharing across organisational boundaries and how we might go about mitigating the risks. The biggest concerns were sharing unpublished and/or sensitive research. We determined that sharing summaries of findings and insights (not raw data, even when anonymised) would be the best solution.
Basic elements service communities need to share
We identified the basic elements that are important to share to make the information useful to others but also easier to share.
These categories can essentially be used as a crib sheet or a summary sheet that research can complete:
- Context (such as service, phase of development)
- Research questions
- Sample size
- User groups/persona summary
- Research methodology used
- Ethical considerations and consent
- Materials and artefacts used in the research
- Summary of findings and insights
Constraints are not just around the sensitivity of data but also the platform that we share on. There is no one, secure tool that all government departments are currently using to share this kind of information. Rather, many different tools are used in different departments.
Pilot testing the summary sheet
After the workshop, we ran a pilot to help us develop the summary sheet that we started thinking about in the workshop. We decided to start small. Rather than testing different types of summary sheets with the people and teams who attended the workshop from several different government departments, we started with just one programme at GDS: the Service Design and Assurance programme with eight researchers on different teams doing different kinds of research. We started with two different styles, a high-level sheet and a very structured sheet.
User Research Summary Sheet Draft 1: high-level
We created this high-level summary sheet as we didn’t want to make too many assumptions about what information someone might share about a piece of research. The hypothesis being that a more structured summary sheet may be too prescriptive.
User Research Summary Sheet Draft 2: very structured
After both summary sheets were completed by four researchers each, we did some high-level comparison and informal analysis of this small sample. It was clear that the more structured summary sheet enabled more useful information to be shared. But not all fields of the table were used or useful. We also identified that the summary used a lot of research jargon. This may be less accessible to people of other disciplines that the summaries were being shared with like product managers, service owners, etc. Based on our findings, we iterated the summary. We created this more structured summary sheet based on the hypothesis that it would a) be easier for the researcher to complete and b) provide more useful information to the user of the summary sheet.
Updated User Research Summary Sheet
The updated summary sheet is now being used by one of the service communities. I hope to get insight into how it’s going in the near future.
Unanswered questions
When is the right time to complete a summary sheet like this? The answer to this question is likely to be different depending on the type of research being done as well as the phase of development. A summary sheet of each sprint of an alpha is unlikely to be useful, for example.
When will we achieve our goal of a user’s view of our end-to-end services? Unfortunately, it seems the end-to-end journey idea is a bit of a distant dream for the time being. But by facilitating the sharing of research, even in the most basic of ways, we’re opening up opportunities to look sideways in a service area. We’re reducing repetition and fostering collaborative working within the user-research community. And we’re trying to encourage a transition in thinking among the many people who make up service communities so that we might someday piece it all together.
For more information on creating better end-to-end services, I recommend How cross-government communities can support cross-government services by Tom Wynne-Morgan and Will Harmer.
