Making user research work in agile sprints
Today, product and design teams are increasingly moving to an agile development cycle. We can see this happening with the rise of Lean Startup and Google Design Sprint. As user researchers we also need to adapt to working within agile sprint cycle to support development efforts, which is usually two weeks long.
In the UK, the Government Digital Services (GDS) have successfully shown that user researchers are embedded within a service (or product) team and work in sprints. So, no doubts the benefits such as collaboration, making quicker decisions and iterating often are realised already. The GDS’ Service Manual also outlines the functions of user research which is a really good introduction for those who are not familiar with this capability in their business.
This post is for user researchers, or a UX team of one, to understand how research activities work in a sprint (and over time) and the changes you can adapt to make research work for the product or services you are designing for whilst keeping track of the big picture.
I will be sharing my experience of setting up research capabilities from the ground up in product/service teams, and the lessons learnt.
1. Commit to a day for research each sprint
Spending a day in research in each sprint sounds like an easy thing to do. In reality it can be quite difficult as it takes commitments from the immediate team to make sure user research happens. In the context of a two-week sprint cycle (ie 10 working days) we’re asking everyone to take a day out to do research. But if you don’t commit to a day to research in each sprint then research won’t happen. The risk is you lose the golden opportunity to speak to your users for feedback before design is finalised or development commences!
I’ve seen this happened to product teams before. When you’re doing sprint planning and discussing what to put through in each sprint backlog there will always be other priorities from the development team or the business to push through. User research will then be de-prioritised. You might hear:
- “We will get to it at a later sprint”- it’s better to get early feedback on ideas before we invest too much time and effort into an idea
- “We don’t have time”- user research helps reduce risks for the team and the business, so a day of learning seems like a good investment
- “The developers are waiting to start work”- doing research is relatively cheap compared to the cost of developing something that doesn’t work for users
So, please block a day out to do research from the start — it is easier to cancel if you don’t think research is suitable for what you’re focusing on for that sprint, or you really run out of time to prepare — than scrambling to find time to take a day out to do research when everyone has different priorities.
From experience, having a regular rhythm is important to help everyone in the product team understand when research happens and also when everything needs to be ready. This includes large ticket items such as research venue, research materials (prototype) to small ticket items such as consent form and visitor passes.
So which day is best? In a 10-Day sprint, Day 8 (sometimes Day 7 too!) is usually the best day to be your research day and Day 9 can be your analysis day. This leaves Day 10 for a quick debrief with the team, agree on actions for next sprint and wrap up. A caveat is that this format is for evaluative research, rather than generative research.
I have illustrated how research and various research activities may look like in a 10-day sprint:
When this is laid out clearly, everyone in the team understand what the expectations are and make sure that important assets, such as prototypes, are ready for research.
2. Collaborate to maximise time
Over the years, I’ve also learnt to appreciate that time is really tight in a Sprint so collaboration is key to maximise the time you have. To get the balance between tight time frame and doing just enough research right, it’s much better to get everyone on the team involved in research activities such as attending research sessions and analysis.
Observe together
Collaboration in research is a quick way to make sure the team has access to users, understand users’ context, pain points and hear feedback directly. Getting core team members to attend research sessions is critical. I’d suggest the core members are: UX Designer, UI designer, Product Owner, Business Analyst, Developers (front and back), and other team members or stakeholders who must know what users experience.
I have also worked on projects, where our end users were professional users so I was conducting research onsite at others’ offices and it wouldn’t have been possible to bring the whole team with me. Therefore, in those instances, it was important for us to rotate between the core team and have one person come with me each time and act as an observer and note taker. If you bring more than one observer then it can become intimidating for the participants.
Take notes & analyse together
Having observers take notes is great. There is an art to note taking in research sessions though. Sometimes, we may have introduced biases to our notes subconsciously. For instance, we start adding our own interpretations of what the participants meant to say and even including solutions to the notes and this may not be what the participants have actually said or done! My tips to the team have always been- take down note of what has been said word by word (or as close as you can) and after analysis we will have the chance to go through any solutions (and you will get some great quotes too!)
There are great collaboration tools that makes note taking easier, such as Miro (formerly RealTimeBoard), Trello or Google Sheets, and add one insight per card. Good old Post-It notes work just fine too. And with auto transcribing services becoming smarter/accurate I have my fingers crossed that the end of note taking is in the near future and that allows us to keep a true record of what happened.
Debrief in between sessions together
I used to make the mistakes of scheduling back to back research sessions or leaving a small gap (10 minutes) between sessions. In reality, sometimes sessions do run over — your participants could have been slightly late, the technology god might not have been on your side, and voila your intended break time to freshen up or have a snack is gone!
Nowadays, I give myself a generous break of 30 mins (if schedule allows) to account for any incidents, and in between session try to run a quick 5–10 minutes debrief sessions with the team to talk about the sessions we just had. The debrief has two key questions:
- What did you hear or see that was surprising?
- What did you hear or see that wasn’t surprising?
This allows the team to quickly remember the key things that they had focussed on, and a chance for me to hear from them what they weren’t expecting or found interesting. It’s also a gauge for me to see if I needed to fine tune any areas of the session or questions that we wanted to focus on in the following sessions.
3. Track your research impact
When I talk to the teams I work on about this topic, a common misconception could be measuring the exact impact that a research has on the final product or service. It is true that would be very useful but in reality there could be many contributing factors making ‘research’ difficult to isolate. But, I’ve tried some different ways that you can track how research have helped shape the product or service over the years:
In your team:
- Constant review of user needs discovered, met and validated.
- Use hypothesis-driven design as an approach to show validated and rejected hypothesis
- Show how research has changed people’s interests in research activities- this could be making notes of number of research observers and note takers
For your products and services:
- Decide what measurements will determine the success- some user needs may only be met when we can see some quantifiable results eg reduction of call volume
- Make a note of when a user need was discovered (eg in Sprint 3) and when you believed the need has been met (eg in MVP when we tested the product and received positive feedback)
I have shared more thoughts on how you can measure impact in my recent talk at User Research London in 2018 and a write up my talk is also available.
When you’re going at a fast-pace, as it often is with Sprints, we can often lose sights of the achievements or see this tracking activities as administrative. But, when the product is launched or 6 month down the line someone in the management team wanted to know how the team made the decisions they had made then it is important to have a trail. It is also a wonderful way to take notes of lessons learnt and to celebrate the impact you’ve made!
4. Iterate your process
What I have shared with you is a very personal view and approach of how I conduct evaluative research in a tight timeframe. As with any design ideas, give the process a try and adapt it to fit you and your team. Every team has a different dynamic so work with your team to fine tune a process that ensure research is embedded into it.
Change isn’t easy, it will take time to build momentum.
Happy Sprinting!
If you have any questions about how to make user research work in your team or organisation drop me a note. Always happy to chat.
I founded Melon Experience Design to help clients understand their users to design and build better products and services that works for them, so get in touch if you would like to work with us.
