The programme to redesign and rebuild 25 exemplar services is now nearly 2 years old. We have 8 services live and 15 services in different stages of beta.
User needs and user research have been at the heart of the programme. We’ve learned a lot, and we now have a pretty good idea of what good user research for government services looks like.
We've written a lot about these things over the past year. Here I summarise the 8 most important lessons we've learned, and point to previous blog posts for deeper reading.
1. Start with user needs. Start in discovery.
In the past, government projects started with policy and legislation, and were worked out through system requirements and procurement. There may have been a bit of usability testing near the end of the project, but too little and too late to have any significant impact.
On the best exemplars, user needs have been at the heart of the project, and user research started on day one.
Here's how this helped:
- Insights from user research have given the entire team a deep and empathetic understanding of their end users
- Product managers know which service features are most important in delivering value to end users
- Teams can constructively challenge policy and legislation to deliver services that work well for people and for government
Our user researchers work with project teams throughout a service lifecycle. They’re not just testing usability, they’re researching with users and feeding insights back to the team all the time. - Leisa Reichelt
Read more in User research not just usability by Leisa Reichelt and Epic win: identifying high-level user needs by Amy Whitney.
2. Embed user research in the project
As government organisations started to hire user researchers, many set researchers up like internal agencies - taking briefs from projects and feeding back results.
This approach has consistently failed. Researchers can’t keep up with the agile project cycle, so research is always too little too late, and findings have little impact.
We work hard to get the whole team involved in user research. We have designers, product managers, business analysts, developers and content editors watching and, even better, helping run our research activities. We do joint analysis and feed findings quickly into the agile workflow. - John Waterworth
On the exemplars, and in our other work at GDS, we get the best results when user researchers join agile teams. We do everything we can to make the insights we’ve gathered from users part of the team DNA.
Read more in From chickens to pigs by John Waterworth and How HMRC got a whole team involved in planning user research by David Travis.
3. Research in every sprint
The greatest benefit of having user researchers join agile teams is that we can commit to the heartbeat of sprints, standups and retrospectives.
Researching with real users in every sprint helps our teams learn quickly and rapidly iterate their ideas. This helps reduce waste by quickly exposing bad policies, and weak designs and implementations.
And just like the rest of the team, we’ve abandoned grand research plans. We now use the things we’re learning and making this sprint to drive our research activities for next sprint.
Rather than a team of researchers taking research briefs from lots of project teams, each project team has a dedicated researcher working closely with the team of designers, developers, content designers and product owners. This allows the team to be closer to the product design and adopt a more ‘experimental’ approach – hypothesising about what design or content approaches might work and designing ways to measure what is more or less successful. - Leisa Reichelt
Read more in How we do user research in agile teams by Leisa Reichelt.
4. Embrace a large and diverse user population
Many of the exemplar projects are delivering services that will be used by millions of people. These user populations have a wide variety of skills, circumstances, experience, aspirations and motivation.
The best user research fully embraces this diversity.
It starts with any existing evidence about users with specific needs, and works hard to meet and learn from those users. Where little is known about the user population, researchers start with a broad mix of participants and identify specific groups as they learn more.
The best user research is inclusive. It considers accessibility and assisted digital support throughout.
Read more in Including users with low digital skills in user research by John Waterworth.
5. Everyone sees 2 hours research every 6 weeks
There’s good evidence that the best way to improve the design of a service is to make sure that every team member gets to watch real people talking about the service and trying out the team’s designs.
One simple aim can transform not only the way people work as a team but also the product they’re working on. Do you want to know the secret? Exposure hours. - Dipa Shah
We’ve encouraged all the exemplar teams to get their ‘exposure hours’ and we’ve seen the value time and again.
Teams quickly develop a greater empathy for their users. They know how the service fits into users’ lives. They learn the language that real people use to describe aspects of the service. They understand users’ frustrations and joys.
Also, teams talk less about how they would use the service. Instead they wonder how a new design would work for the person they saw using a screen magnifier, or how the teenagers they saw last week would answer a newly worded question.
Read more in Have you had your recommended dose of research? by Dipa Shah.
6. User research is a team sport
As a user researcher I want to help my team learn about users so we can make a better service. - GDS user researcher
On the exemplar projects, the most effective user researchers act more as facilitators than pure researchers.
They work with their team to develop research questions and plan research activities. Team members take part in research activities and get direct contact with real users. The researchers lead joint analysis sessions and design workshops, and work closely with designers, front-end developers and content editors on prototypes.
On these projects the team as a whole learns about its users and their needs, which helps drive both the design of the service and the team’s engagement with policy, legislation and operations.
Involving everyone in user research also helps to mitigate researcher bias, give less dominant team members a voice, and resist uninformed interference from stakeholders.
Read more in Guest post: user research at the Home Office by Katy Arnold.
7. 1 part research, 2 parts communication
User research is only as good as the impact it has. On the best exemplar projects we find that user researchers spend about 1/3 of their time planning and conducting research, and 2/3 of their time communicating with their team and their wider organisation.
The researchers can be explaining research questions and activities, presenting research findings at team show and tells, discussing research video clips in meetings with policy colleagues, creating and sharing longer-lived visual models and infographics, curating research walls, and just being present in conversations and meetings to keep colleagues focussed on research evidence rather than opinions and assumptions.
As well as showing and telling, on these occasions researchers will always be listening and questioning to understand what kinds of communication will work best on their project.
We also find that the most effective researchers create physical and digital materials - research walls, posters, findings slide decks, highlight videos, personas, journey maps, infographics, etc. - that are easy to see and easy to share, and that continue to communicate when the researcher is not present.
As user researchers, our walls are an important and constant broadcast signal. A well-tended wall keeps research insights and user needs constant in the collective ‘mind’ of the project team. - Kate Towsey
Read more in Vertical campfires: our user research walls by Kate Towsey.
8. There’s always time and money for user research
Many exemplar projects have had to overcome this common objection:
We don’t have any time or money for user research.
To get past this blocker we first point out that all projects allocate the time and money they have between the things they need to do. So this is really equivalent to saying that user research isn’t something you need or want to do.
We explain that user research doesn’t have to be slow or expensive. It fits into the regular project cycle and helps reduce waste on things that don’t work and aren’t needed.
And finally, my favourite, we remind everyone that to really waste time and money all you need to do is build a service nobody wants and nobody can use.
Keep in touch. Sign up to email updates from this blog. Follow John Twitter.
4 comments
Comment by damian fulljames posted on
The link in the graphic under Section 1 doesn't work -
This site can’t be reached
https’s server DNS address could not be found.
ERR_NAME_NOT_RESOLVED
Comment by John Waterworth posted on
Hi Damien. A blog post must have moved. I've fixed the broken link.
John
Comment by M posted on
Thanks for this article. We are trying to use this approach for a system replacement where the users of the system will be 2 to 3 people. do you think spending time on UR will be beneficial.
Comment by John Waterworth posted on
Absolutely, yes. If there are a small number of users, you should still understand their needs from your system, and do that quite quickly. With a few clearly identified users, you can still work iteratively, testing with them as you go. You'll just need to be careful that you don't take up too much of their time.