How we do user research in agile teams

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.

Economist/Drupal – Sprint 2 Demo (CRUD-in-place)

Drupal/Economist Project – Sprint 2 Demo from Leisa on Vimeo.

Today is Demo Day at The Economist, where all the various SCRUM teams will show and tell what they’ve achieved in their latest iteration. I thought I might see if I can get into the habit of pre-recording my demo so I can share it with you here and ask for feedback & advice! So, here we go!

In the past two iterations (this project runs on 1 week iterations) we’ve done a combination of research, design and testing the publishing tools that the editorials staff will use to administer what is known as the ‘Channel Index Pages’ – these are pages that you’d land on if you clicked something in the navigation that said, say, Business & Finance, or Science & Technology, and their job is to pull the most interesting current content to the top so that readers can access it more easily.

These pages are made up of a range of elements, most importantly for this demo are News Packages (consisting of a lead story and related stories/media files) and what is known as the Bloggy Chunk (an editable text area that section editors can freely input their own content, it is still very much a work in progress and is variously used as an aggregator for recent interesting stories that The Economist isn’t covering in depth or to highlight interesting reader comments, it may in the future show content from an RSS feed).

Although working within the SCRUM methodology, I am trying to take a systemwide approach to the design as far as possible, so there has been a whole range of questions that I’ve had to consider that aren’t strictly in the ‘stories’ for our sprint (logging on, activating editing, for example), and similarly, I’ve tried to devise interaction approaches that will be reusable across the other parts of the system that we have yet to design rather than just customising the design approach to this individual problem set.

The design approach shown in this demo is still quite lo-fidelity and ‘broad brushstroke’, it will become much more precise over time, at the moment my priority is to try to work through and communicate the ideas as quickly as possible – giving me more time to explore a range of approaches, and to iterate approaches which has been very valuable.

So, if you have a moment and are so inclined, I’d really love to get your thoughts on the approach we’re taking so far. We’re also about to embark on starting some development work on this – to make sure we can build it in Drupal without too much difficulty – so if anyone has any guidance on how best to approach this, modules we should take a look at, anything else you think we might need to know, I’d love if you could share it here!

Look forward to hearing from you and thanks in advance!

(apologies to anyone who saw the first version of this blogpost with the screwy audio synching)