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.
Follow Leisa on twitter: @leisa
8 comments
Comment by John posted on
Hi Leisa,
What training is available for anyone wishing to become a GDS qualified User Researcher, and is it openly available to all, or civil service only?
Comment by Leisa Reichelt posted on
hi John, we're working with Civil Service Learning at the moment to come up with a course that will be available to Civil Servants to begin with, then hopefully available more widely in the future.
At GDS we do User Researcher Induction Training every other month that is a good starting point for understanding how we do user research - that's open to anyone who is working for govt at the moment - email me leisa.reichelt@digital.cabinet-office.gov.uk if you'd like to find out more about that.
Or if you're on the Cross Govt User Research Community mailing list you'll find out about regular meet ups we have where we often do training on different aspects of User Research. Again, email me if you'd like to join that list.
Hope that helps!
Comment by Matthias Schreck posted on
Hi Leisa, thank you very much for sharing this - over the last year or so we've also tried various things to make research and design a smoothly integrated part of the agile teams across our company.
I'd be interested to learn from you how much time researchers spend with the rest of an agile team for each sprint. You suggest that a large part of the team would take part in the analysis sessions, and that some of them are also accompanying the researchers during their visits and tests. Let's say there's a 2-week sprint schedule, how many hours would you suggest researchers, designers and developers would spend in the same room together?
Comment by Leisa Reichelt posted on
hi Matthias, We try to make sure that each product team has a researcher as a dedicated part of the team, and our current thinking is that you need them to be available to and working in close proximity with the team for at least 3 days per week. Our researchers sit with their product teams, not with the research team. This allows them to be available to work with the designers and product managers to shape the product, as well as to coordinate and facilitate fortnightly qualitative testing, as well as potentially some other different kinds of research (larger scale quantitative studies, A/B testing, etc.)
Comment by melissa cliver posted on
Hi Leisa, can you also explain how you synthesize your findings, if that is also a team experience and how the learnings are documented and shared? Also if project team a's learnings are shared with project team b?
Comment by Leisa Reichelt posted on
Great questions Melissa, and we plan to write a whole post detailing this process in the near future.
In short, we capture findings to post it notes during the user research sessions and then use those to do an affinity sort (you can see an example in the picture above), grouping similar things that we observed or heard people say or do together. Each of those groups then generates two things - a research finding that we capture into a research library (they're the pink post it notes) and actions (the orange post it notes), that go into the project back log to be done in the next sprint or to be planned into future sprints.
Part of the reason that we do this using post it notes is that it helps make this process collaborative - we often have half a dozen people participating in the analysis sessions on the project I'm working on. We find this really helpful because it helps make sure that we all agree on what we actually saw in the study and what we think it means, and then we can quickly work together to decide what we need to do about it. Sometimes those are obvious fixes or changes, and sometimes the action is to have a design workshop to more fully explore different ways to address the issue we've identified.
We share the findings in the research library I mentioned, but we also have internal blog posts for our team and project stakeholders that share what we've learned in a more narrative and interesting way that we try to post the day after we've done the research.
Comment by julia posted on
An intriguing process, based around post-it notes. Is the research library you mention an online thing though - or people just have to trawl the walls for pink post-its? If the latter - what about teams base din other locations, or longevity - or context? Despite best intentions, most of my post-it note bundles do eventually end up in a bin, having never been seen by anyone other than the original workshop participants.
Comment by Leisa Reichelt posted on
hi Julia, The post it notes really just help facilitate the collaborative thinking process, they are not long term artefacts. The findings (pink post its) go into our research library - we started using a customised version of WordPress for that but we are not experimenting with Evernote Business (inspired by the team at Mailchimp). We do often photograph our post it notes and put them into Evernote (along with the actual findings in text), but they do end up in the recycling bin quite quickly. The orange post its (actions) end up in the product backlog, this might stay on the wall for some teams but most have some kind of software they're using to manage their project backlog. Making sure that the findings are captured in a way that will have ongoing value is very important to us - still a work in progress but a high priority. Hope that helps.