3 Tips for UX Research in Agile
UX research serves as the vital foundation of any project, adding context and insight to the design process, but it often suffers the most in an Agile framework. It is tricky to insert traditional user-centered design methodologies in general into incremental, development-focused sprints. This is curious as Agile presents as an alternative to traditional waterfall phasing by blending and incorporating those very phases — research, design, development, and testing — into every iterative sprint.
Research is the backbone of both design and business decisions, and ditching it in the face of time constraints creates inefficiencies for development. Here are three tips to embrace the constraints and keep UX research as a fundamental part of Agile.
Tip #1: Take Advantage of “Sprint 0”
“Sprint 0,” or the period of time before the first sprint that delivers real progress, gives the development team time to prep and setup a basic framework to complete future work efficiently. Similarly, this is a time when initial discovery is taking place for the UX team, allowing design to simultaneously progress with, if not be slightly ahead of, the development team come Sprint 1. It is also an appropriate time to plan for how research will be interlaced into each future sprint.
In Agile, discovery is an ongoing activity spanning the entire project — not a one-off phase at the beginning. Prepare a handful of research activities that will work well in a short time frame and can be taken advantage of at any point throughout the project. In a recent project here at Blink, we used three research activities regularly (below in Tip #2), conducting the one that best fit the needs of that particular sprint.
Procure a pool of participants up front in order to save time and execute on research activities quickly. This is easier for enterprise and internal team UX projects, as a motivated and willing user base already exists. It can be accomplished with consumer facing projects by creating an umbrella user profile ahead of knowing what will actually get tested. The user profile should be broad enough to work for any aspect of the project and allow for easy and quick recruiting to take place in advance of each sprint.
Tip #2: Adjust Activities and Work With What You’ve Got
When it comes to research methods it is important to be flexible but still adhere to best practices. In a Nielsen Norman Group article on When to Use Which User-Experience Research Methods, Christian Rohrer presents a framework for choosing the right user research method at the right time. He also points out the importance of choosing a research methodology that best fits the objective of the given product development phase. Rohrer concludes with, “While many user-experience research methods have their roots in scientific practice, their aims are not purely scientific and still need to be adjusted to meet stakeholder needs. This is why the characterizations of the methods here are meant as general guidelines, rather than rigid classifications.”
“… adjusted to meet stakeholder needs” is the fitting takeaway for UX research in an Agile setting. All phases are happening concurrently, iteratively, and quickly in Agile. The need to conduct research may be unknown until the day before. In these circumstances it is important to remember what UX research wishes to accomplish — to glean insights, to inform design — and work with what you’ve got while keeping sound research practices in mind.
Here are three adjusted research activities Blink recently used within the Agile time crunch:
In traditional user interviews participants meet one-on-one with a researcher to discuss in-depth any number of planned topics. A note-taker may also be present in the room, and sessions are usually taped (with permission) for further analysis. To expedite the “finding to implementation” process, we encouraged stakeholders and developers to observe the interviews in real time using a web conferencing service. The observing team are mostly there to listen and learn but can message clarifying questions to the moderator. It is still the moderator’s job to adjust any leading or derailing questions that come in from the team.
To help the participant feel more comfortable and open to being observed, put extra emphasis on the fact that they are not being tested. Let them know the team is there because they value the participant’s feedback and want a deeper understanding of user needs. For enterprise users, it is especially important that they know their performance and standing in the company is not affected by their honest reactions and opinion.
Contextual interviews allow researchers to watch and listen as the participant works in their natural environment. These are usually unscripted, and researchers can take a “fly on the wall” approach to understanding how a user works, chiming in with any clarifying questions. In an Agile time frame, we often need a contextual interview to touch on specific scenarios we hope to learn more about. To do this we combined contextual interviews with a task analysis — watching users do their daily work while also asking them to perform specific tasks that meant to inform the design and development goals of the current sprint.
Usability testing isn’t a method that necessarily has to be adapted for Agile. It is within good usability testing standards to conduct a study outside of a lab, with a low-fidelity or incomplete prototype. Great results can come from conducting a test in users’ own work environments or out in the wild (guerilla testing) — it may even elicit more honest and realistic feedback than an artificial setting.
It’s challenging to put together a polished end-to-end prototype in any kind of project, and in an iterative and incremental framework it can even be contradictory. Focusing on the goals of the current sprint, the prototype only needs to address the pieces needing analysis and reflect the current state of project progress.
Tip #3: Ditch Documentation (For the Sake of Documentation)
Keep session guides lean. Some organizations may require a detailed protocol of the session prior to conducting research, but in Agile, it makes sense to keep the script simple and informal. Sure, the interview should have structure, but remember it only takes a little prompting to get to some new and unanticipated discoveries.
Let go of robust findings documentation, focusing on what is being designed rather than the artifacts. User researchers and research-savvy designers are already embedded in the greater sprint team, and post-research, are primed to go ahead and take action on the findings. Blink teams have accomplished this with ad-hoc workshops, debrief meetings, immediate design turnarounds, and tasking.
Ad-hoc workshops are used to verbally go over findings with the entire sprint team. It’s helpful if team members outside of the UX research team were involved in observing the research activities. During this time, we reflect on what everyone saw and heard during the session, and common themes are triaged and assigned to owners right away.
In lieu of a high-level key findings presentation, debrief meetings are set up shortly after research sessions to share feedback with stakeholders immediately. This gives stakeholders visibility into the project and gets issues in need of business decisions on the table. Instead of looping back around some time after a presentation, findings can be turned into action items for the sprint team on the spot.
There are times when it makes sense for the UX team to go ahead and make design decisions without buy in from stakeholders or the rest of the team. Immediate design turnarounds let the UX team take what they found and make design updates accordingly. The key here is communication. The development team should be made aware of updated wireframes or visual designs, so stories stay aligned.
Tasking is appropriate if a finding needs further discovery — business buy in or technical feasibility — before moving forward with design. Blink uses work tracking apps such as Asana to manage tasking. Work tracking apps help make clear what the question or action item is, who is responsible for it, who should care, and when it is needed by. It is also a convenient space for collaboration — team discussions can continue until a work item is resolved.
As our clients continue to adopt Agile to handle complex projects, we’ve learned to accept the constraints, and keep in mind that adapting methods is better than no research at all! With a little planning up front and a little creativity and flexibility throughout the project, we are determined to keep UX research in the Agile mix.
Irene is an interaction designer by day and musician by night. She believes empathy and understanding are key to creating positive impact in both of these arenas.