The case for Agile user research

As a consultant and designer I spend lots of time doing user research. Traditionally on projects, there is ‘a phase’ for user research. This phase involves thinking through all of the questions to be answered in the user research, completing any number of workshops, interviews or experiments and then doing a whole bunch of synthesis. While this way of working does deliver insight it has a key limitation: you address the same set of research questions during the entire research phase.

The problem is that there is little time to give emerging questions considered attention. If new questions are addressed, it is in an ad hoc way. There is little time to craft a new discussion guide or create new artefacts to test with your users. The fast pace and singular focus from the beginning to the end of the research phase can ultimately hamper your ability to extract the most value from your interactions with users.  

Benefits of Agile user research

In my work at BCG I have been infusing Agile practices into my user research. Completing user research in an agile fashion over the course of a project means that I conduct research throughout rather than just in one specific project phase. Benefits I’ve found include:

1. Running user research in sprints gives you natural break points. This gives you time to reflect on what you’ve learnt and ensure you are asking and answering the most important questions in the next sprint.
2. You get to continuously synthesise after short bursts of customer engagement rather than weeks of research.
3. Agile has inbuilt ceremonies that mean you regularly share customer insights with the project team and other stakeholders so everyone is across what you are learning and can input into what questions are outstanding.

 How to do agile user research

 Agile projects are run in sprints – I suggest completing 2 week sprints as they give you enough time to complete all the steps but are short enough to maintain a rapid pace of discovery.

Planning the sprint

1. Create your backlog. This should be a list of the topics you want to research over the course of the project. These should derive from your research objectives. The research objective should be formed with members of the project team and relevant stakeholders. The researchers or designers take those objectives and break them into discrete user stories or tasks that could reasonably be addressed in a two week sprint. The user stories may be outstanding questions your team has, artefacts you want to test or hypotheses you wish to investigate.
2. Prioritise the backlog items so that the most important ones are at the top of the list and the less concrete and less important ones are at the bottom. Make sure to involve the right people in this process so that the priorities adequately reflect the overall project objectives. This may be a senior member of the team, a client or another project stakeholder.
3. Size the top user stories. Think about how much time it will take to complete each user story and allocate a value to each one.
4. As a research team, agree how many user stories you can complete in the sprint. Think about the project timeline as well as the capacity of the researchers in the sprint. Over time you will be able to use the values you allocate in step 3 to build a solid understanding of what’s realistic to complete in a sprint. 

 During the sprint

1. In each sprint, complete the research for the user stories you have identified for that sprint. Completing the research includes writing the discussion or facilitation guide, completing the research (interviews, workshops, experiments) and doing the synthesis (creating an insights report, archetypes or other way to bring the insights to life).
2. Recruit for the following sprint. You need to do recruitment one sprint ahead, so you have adequate time to secure participants for your research.
3. Share your research findings during the sprint showcase. Share the most important research as well as the implications for the project overall. Make sure to share back with those same stakeholders who helped with the backlog prioritisation.
4. Conduct a project retro focusing on the research process. Examine which techniques worked well and which did not. Think about what needs to change for the next sprint. 

Sprint Planning (for the next sprint!)

1. Revisit the backlog. Add any new research questions that arose over the course of the sprint and then re-order it to make sure the most important questions are at the top of the list. Go through the same process of deciding how many user stories to tackle in the next sprint and sizing each question appropriately.
2. Conduct your next sprint as you did your first one, applying lessons learned from the retro.

 Conclusion

 Using Agile methods to manage user research may feel unusual to start with. Ultimately, I find that working in an agile way is the best way to respect the time customers offer during research and to create the most value on projects.

 The  views  expressed  in this article are  mine  alone  and  do  not necessarily reflect the views of my employer