Leisa Reichelt, my predecessor as Head of User Research at GDS, recently wrote about her rules of thumb for user research.
One of her rules was ‘One researcher per team’. By this she meant not spreading researchers thinly across several teams at once, but letting them focus on one team at a time. Leisa said that this would ‘let researchers do a good job for at least one team rather than a mediocre job for everyone’.
On social media I responded that I thought this was the most important rule. It’s what makes all the other rules work.
Building ownership and trust
Letting a user researcher focus on one thing at a time helps them to understand and focus on their team’s most important questions, and to quickly adjust research activities as the team learns and priorities change.
It gives the team ownership of their own research. So it becomes something the team does - not something that’s done to them or for them. As well as making the research more effective and actionable, this builds trust between the user researcher and their team.
Having user researchers work on one thing at a time also makes it much easier for everyone to get involved. To watch real users, visit them, listen to them, understand them.
All this means that teams are much more likely to believe in the value of user research and to respond positively to research findings.
By comparison, when user researchers are involved with a number of teams but not fully committed to any one, their findings are too often late, irrelevant, and ignored or rejected by teams. To use a fable I wrote about, they are chickens, not pigs.
Building teams
As teams work regularly with their own user researchers, everyone in the team gets better at joining in user research activities and integrating research findings into their ways of working.
And having user researchers working on one team at a time produces better conversations about priorities and limiting numbers of things in progress.
When user researchers are spread across teams, they rarely have enough time with each team to make a real impact. They can easily become a blocker. And can get burned out by competing priorities.
Building communities
While a dedicated user researcher helps a team to integrate user research more fully into their work, there’s also a danger that research findings become siloed and not shared across teams.
Having lead user researchers working across a cluster of related teams can ensure that valuable findings are shared and used widely.
They also help to move researchers between teams to align research to wider objectives, ensure good practice, and help researchers develop their skills and experience.
This way of working gives more senior user researchers the time and support they need to try new approaches.
And more junior user researchers can work together with more experienced mentors on larger teams. Or they can work on smaller, lower-risk teams, with support from nearby seniors.
Combined with communities of practice, these stable relationships across teams support better practice and career development for researchers.
Nothing new under the sun
In the Service Manual we emphasise the importance of making user research a team sport. And we’ve been blogging about this since we started the user research blog.
It’s not our idea. For example, this article about designing the Windows 95 user interface describes an agile process of iterative design with embedded user research.
But then I’d say that none of the things we’ve been doing to make government more user-centred are really new.
It’s just that we’ve found ways to do those things consistently, at scale.
And it’s embedding user researchers in multi-disciplinary services teams that makes that possible.
Follow John on Twitter and don't forget to sign up for email alerts.