Incorporating Agile UX research | Part 2
Logistics
Originally published by my friends at www.userzoom.com on March 23, 2017
Last time we talked about how to prepare your team for integrating agile research. This time we’ll discuss some of the tactics of implementing and synthesizing findings as a team.
The sheer logistics of performing research as quickly as called for in Agile can be daunting at first. The first time I was on the hook to plan a test, recruit participants, run a study, and analyze in a 2 week sprint, I mentally prepared myself to fail miserably. How on earth was all that possible in that time frame? Sometimes recruiting alone could take several weeks.
There are lots of methods of creating something to test quickly, but how can you streamline all the logistics of running research to keep pace? Here are a few tips that have worked for me:
- Set a research time every sprint and hold it sacred. No meetings, no dentist appointments, no ifs ands or buts. You want everyone on the whole team to know this time is important, and it gives everyone a chance to come see the sessions. Once you’ve set aside the time for yourselves, it also means you can start recruiting people regularly. Even if you haven’t yet decided what you’re working on in a sprint, you may know you want to target a specific persona and start contacting them to get something in their calendars.
- Build up your own database of participants. Identifying, reaching out to, and then screening participants can be a cumbersome process. Have a group of willing participants can really speed up the process. If you have existing users, you can set up a screener survey and invite users to sign up via normal communication channels like emails, post it on your website or social media outlets, or invite customers who contact support. You could also recruit participants who aren’t yet customers with social media posts. Continue to recruit people constantly and build up a pool you can contact over time. More on participant recruitment here.
- Allow self-scheduling. One of the biggest time-sucks in recruiting moderated sessions can be the back and forth of finding a mutually agreeable time to meet. Since you have a set block for you to conduct sessions, you can use one of the many scheduling tools to let participants book their own block of time. I’m a fan of pow wow, but Calendly is also popular and there are bunches of others. The key is to look for something that will let you send customized confirmations and reminders with contact information.
4. Use an unmoderated tool with a built-in panel. Then you don’t have to deal with any of this! You just set up the test, set the screening questions for respondents, and let the results flow in.
Learning as you go
Once you have the logistics in place to run sessions consistently, the biggest challenge will be figuring out what to do with all the information collected and what the team should do next.
As a reminder, it helps to set up the research properly with a specific research goal and hypothesis. If you know exactly what you are looking for, it’s much easier to decipher the story that the data you’ve collected tells.
Let’s say you’re working on incorporating a new item into an e-commerce platform and want to determine where it should live. Maybe you have a hunch that it should live in a specific category but some of your teammates aren’t sure. Your hypothesis could then be something like, “I believe users will be able to find product A in category B.” Then you keep track of how many people are and are not able to find the item during your test.
This is a very straightforward example, but it’s amazing how much easier it is to synthesize research when you have a clear hypothesis.
Involving the team
You should also take advantage of Agile’s emphasis on cross-functional, collaborative teams and get as many members of your team as possible involved in watching research sessions, whether that means observing interviews or reviewing remote session videos.
You can still take on the brunt of planning, but you want the team involved in viewing sessions. This is especially helpful for the researcher because someone else can take notes and you can really focus on running the sessions. I like to have the team take notes in a simple shared spreadsheet, with each participant listed in a row and the key research goals listed across the top. That way, anyone watching can add notes in a relevant place.
Having the whole team involved in sessions helps with more than just session logistics. A lot of non-UX researchers are abstracted from users. Developers and business representatives might read reports or hear stories about frustrations, but there is nothing quite as illuminating as watching someone grimace their way through an interface. You want the whole team to be learning the frustration points and areas of opportunity together.
That not only makes a bigger impression on the rest of your team and builds empathy with your users, but you spend less time documenting what happened and more time working on solutions together. Everyone learning together means there can be less opinion-based debate and more data-based decisions, which lets you all move faster.
Debriefing
You can have a debrief session immediately after the final session where everyone shares their key takeaways, discusses priority of findings, and starts brainstorming solutions that address experience issues and account for technical feasibility and business perspectives. You won’t have to worry about convincing people to buy-in to your recommendations or figure out whether they can be built, because the whole team will be there to come up with the next steps. Rather than ending the research sessions with a report of what you found, you can end with the team having a shared understanding of findings and the beginnings of a plan to solve issues or shift things.
You might want to incorporate the research debrief as part of the planning session for the next iteration of work. Since there is already time set aside for teams to plan in most variations of Agile, you won’t be asking for additional meeting time from your team. Just be careful to keep the focus on understanding the data you just collected and setting the frame for the work that needs to be done next, rather than trying to completely solve issues then and there.
You could even schedule debrief sessions after each participant and see if there is anything minor you could change between sessions to improve the experience. For instance, if two users in a row can’t find an item, a developer or designer might be able to quickly update a prototype or test version that you can show the next participant. That way, you don’t spend a whole chunk of time confirming that something is broken. Rather, you can get some rapid feedback on different versions and pick a direction based on the data you collect.
Wrapping up
It can take an adjustment if you’re transitioning from a traditional Waterfall culture, but there are definitely some logistical and team adjustments you can make to incorporate UX research in an Agile environment. I’ve found taking advantage of Agile’s focus on collaboration between cross functional team members can actually maximize the impact UX research is able to have across the board.
In the next installment of the Agile UX research series, we’ll discuss how to keep up with the volume of data you collect when you perform Agile UX research.
Amanda Stockwell is President of Stockwell Strategy, a UX research practice focused on lean research methods and integrating user knowledge with business goals to create holistic product strategies. She has focused most of the last decade focused on finding innovative ways to understand people and embed that knowledge into overall process. She’s lead teams that provide research, design, and UX strategy services and frequently writes and speaks about her experience. Check her out on Twitter @MandaLaceyS and view her #LinkedInLearning courses on Agile UX Research, UX Research Basics, Card Sorting, and Interviewing.
