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 multiple teams, 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

Embedding user researchers in teams 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 research embedded in the team 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 work as internal ‘agencies’ serving multiple teams, their findings are too often late, irrelevant, and ignored or rejected by teams. The researchers are involved with a number of teams but not fully committed to any one. To use a fable I wrote about, they are chickens, not pigs.

Building teams

Embedding user researchers in teams delivers on the agile promise of multi-disciplinary teams that include all the skills needed to do their work.

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

Combined with communities of practice, having more stable relationships within teams supports better practice improvement and career development for researchers.

More senior user researchers have the time and support they need to try new approaches.

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.

Lead user researchers can work across a cluster of related teams to align research to wider objectives, to ensure good practice and to help allocate people to the right work to develop their skills and experience.

Working in a ‘resource pool’ and moving quickly in out and out of teams makes it hard for the community to sustain these valuable relationships.

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.

Original source – User research

Comments closed