Originally published on the GDS Blog
Getting user research into agile teams in a way that is timely, relevant and actionable is a challenge that teams the world over are tackling. Working effectively in agile has recently been the driver of some fairly significant changes to the way our researchers work at GDS.
In the early days of GDS, the User Research team worked across the different projects here, as well as helping support the exemplar transactions. We did a mix of in house research, as well as managing usability testing and other research that was outsourced to specialist companies.
Using this model we found it difficult to provide insight to teams quickly enough, and researchers were spread across projects to the extent that they were never really a part of the team shaping the design or developing real depth of expertise in a particular product or its audience. This was less than ideal for both project teams and researchers.
We’ve been iterating how we do research in the same way we iterate our product design, and learned that the following techniques seem to integrate good research into agile teams more successfully.
Dedicated researchers for each team
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.
Test designs at least every fortnight
The ‘two week rule’. We don’t design anything for more than two weeks without watching real end users interacting with it. This means that most teams are out in the field or in the research laboratory at least every fortnight, putting our design and content in front of potential end users.
Everyone in the team should take part
We believe that research is a team sport and encourage all team members to observe research sessions for at least 2 hours ever 6 weeks. There is good evidence that this helps teams create better products. And having dedicated researchers in our teams makes it easier for everyone on the team to get regular opportunities to watch people use the product they’ve designed.
A varied toolkit
It’s easy for teams to get comfortable with a small set of research methods and to use those for everything. An experimental mindset requires that we are always looking for better ways and a more varied research toolkit to help us get a richer and more accurate understanding of our users and their needs.
We use a mix of qualitative and quantitative methods and work closely with our web analytics colleagues to design studies that allow us to better understand how people respond to interface design and content using A/B testing and detailed path analysis in early prototypes.
See it through from analysis to action
Getting interesting insights from research isn’t hard. Getting those insights into the design of products can be surprisingly tricky. We analyse our research collaboratively and make sure we extract both findings and actions from each study. Findings build our understanding and go into our research library. Actions go into the project backlog, into sprint plans and therefore into the product design.
We don’t do powerpoint presentations or detailed reports and we use the time we’ve saved from that to work more closely with the team.
Sharing what we learn
As we do more research in more of our teams, there is a lot to gain by sharing our findings. We’re experimenting with ways to capture and share research across teams and even across departments, so that research becomes a real valuable and reusable asset for government.
We’re iterating how we work in the same way we’re iterating our projects. As we find better ways to work within teams and within the agile framework, we are better able to help teams build empathy with users and shape products that are focused on their needs.