The Agile approach to product development focuses on continually and quickly releasing, learning about, and improving a product to enable sustained movement forward. By focusing on incremental improvements rather than a finished product, product teams can learn and pivot as needed to maintain their competitive edge. Most product teams use, or are moving toward, some form of an Agile methodology to rapidly and incrementally evolve their product or service. The good news is that user experience research and design can fit into the Agile process quite effectively.
Learning is a hallmark of the Agile methodology. At the outset, product teams need a solid understanding of their users, as well as key use cases and task flows, to ensure that they are solving the right problems. As development progresses, product teams need a continuous and fast feedback cycle to support decision-making. Teams need to learn whether their incremental improvements are headed in the right direction or if it’s time to pivot.
While user experience researchers can be key to facilitating this learning process, adapting your research approach to an Agile process can be challenging. We’ve each been down this road and will describe lessons learned from our experiences working for a variety of companies where we have introduced lean research to fast-moving product development teams who were focused on incremental improvements.
Just Get Started
Whether you’re conducting research in-house or as a consultant, you just have to start. Most product teams are hungry for research. They want insights into their customers so that they can build better products. Capitalize on that shared fate. Odds are good that you won’t get it right the first time. You’ll learn what works and what doesn’t and make adjustments along the way.
Consider your team’s velocity
Product managers and engineers like the idea of getting user feedback, but they want it delivered at the same velocity as their product development cycle. To meet this need, we have set up feedback sessions that fit within the team’s rhythm, whether they are weekly or bi-weekly. Our goals are to deliver actionable results to inform the particular sprint and keep the team moving forward.
Work with what you’ve got
You don’t need fully functioning systems to get feedback. Start by putting whatever is ready in front of your users, whether it be sketches, design mockups, prototypes, or working code. Use what you can get your hands on and focus on the most pressing questions. Fully fleshed-out usability studies aren’t necessary for learning to occur.
Go Where Your Team Is
If you’re trying to get a lean research program off the ground, start by identifying your stakeholders and how to best engage with them. If you’re not meeting the team on their turf, you’re adding yet another hurdle to their participation, interest, and ultimately, empathy for the user.
Leverage your team’s tools
Product and engineering teams often have one tool where the magic happens—the tool used to open, track and close tasks, host discussions, and document measures of success. Teams often live in this tool. If you want your stakeholders to be actively involved in your research, it should live in that tool (see Figure 1). For example, if your teams use a tracking tool like Jira, jump in alongside them. We’ve used Jira to track and document all research planning and results reporting. For example, each round of lean research got its own Jira ticket where we attached all planning materials, including the test plan, session schedule, interview guide, and links to prototypes where applicable. The ticket also contained all research results. After each session, we published a session synopsis as a comment in the ticket and included a link to the session video. Within 24 hours of the final session, we published a top-line summary across all sessions. No fancy reports; it was all in Jira. Where appropriate, we called out particular team members in comments, triggering an automatic notification from Jira.
Using Jira connected us with our team, facilitated quick delivery of information, and streamlined and simplified our documentation, ensuring that only the most relevant information was documented—an Agile best practice. We’ve found that leaning on those tools that are part of the team’s culture and process helps to facilitate participation in research sessions, as well as the consumption of research results.
Sit with your team
We’re big believers in embedded UX. A key principle of the Agile approach is business team members and developers working together daily throughout the project lifecycle (agilemanifesto.org). We’ve found that putting UX into that mix means moving even faster and smarter. Whenever possible, we embed designers and researchers with their product teams to ensure close collaboration and a shared, deep understanding of our users and their use cases. Of course, that’s not always possible. So, what happens when team members are not co-located? We lean on technology to break down distance and time zone barriers and virtually sit with our teams: Ticketing tools, virtual meeting tools, messaging tools, and shared documents all help to facilitate information sharing and collaboration. We also plan regular (at least quarterly) field trips to build relationships and allow in-person collaboration when we are supporting remote teams.
Build Credibility
If your team is new to the idea of incorporating user research into their process, focus on delivering results to build credibility. Whether you are part of a product team or brought in as a consultant, you may be met with resistance—often because of resource concerns—but sometimes because the team may feel that they know enough about their users. Your first job is to quickly deliver results, which will ultimately earn their trust.
Start with easy-to-find participants
If recruiting target users is time consuming or difficult, start with proxy users such as client success representatives or sales engineers. Proxy users who regularly interact with your target user can provide a starting point to demonstrate the value of user feedback, particularly to resistant teams (see Figure 2). We’ve had experiences where resistant product team members were surprised by feedback from sales engineers that identified serious design flaws. Learning from these proxy users allowed the team to pivot, transitioning them from being research resistant to research advocates. Bringing in proxy users also facilitates relationship building with the larger team. Strong relationships foster communication and collaboration, enabling teams to move faster.
Lean on allies
If any team members have previous experience hearing from users, amplify their voices when research is being suggested. Designers are often a researcher’s biggest advocate, but if you hear anyone saying, “Hey, I wonder what a user would think about this…?” stop by that person’s desk to chat. Build relationships and foster team members’ curiosity about your users.
Get the team involved
Conducting research at velocity takes a village. We reach out and ask team members for help with all aspects of executing research. Ideally, designers, product managers and developers actively participate in planning meetings and research sessions, even taking notes during sessions. Time is usually at a premium, so we’ve optimized by asking team members to rotate responsibilities, giving each team member an opportunity to hear first-hand from users while minimizing the total time needed to maintain involvement. If you’ve been brought in as a consultant to work with teams who may be siloed, invite your client or stakeholders to your daily stand-ups so that they can personally experience and internalize the process rather than just hearing about it in a weekly one-hour meeting. Active involvement engages the team in the research process, facilitates their understanding and use of the results, and helps to create empathy for users.
Promote drop-ins
Part of fostering team involvement is ensuring a shared understanding of what is happening when. We did this by creating a dedicated shared research calendar that is visible company-wide (see Figure 3). Anyone can see when we schedule sessions and can drop in to observe. The calendar not only promotes awareness of our different ongoing research efforts, but it also promotes the sharing of ideas across functions because people can drop in and observe users interact with designs being developed by other teams.
Low-tech solutions can suffice
Video clips are a great way to put team members in touch with users and key interactions, but clips can be time consuming to create. If you need to move fast, consider taking a shortcut and simply provide your team with the full session video, along with timestamps for key moments across the session. If team members can’t watch a session in person, they can watch recordings and have the option to fast-forward to key moments. Fancy? No. Fast and effective? Yes. Maintain a focus on quickly connecting the team with your users; low-tech solutions can work just fine.
Iterate
The more research you do, the more you learn and the better your process will become. Creating a lean research program is itself an Agile process. Try something out, see what works and what doesn’t, make some tweaks, and try again. Throughout, actively seek feedback from your team and be ready to pivot when something isn’t working.
Aim high, but be open
Timing is critical in an Agile environment and you may need to make adjustments as you learn what works for your team. When we kicked off one of our lean research programs, we aimed for a weekly cadence, inspired in part by Nielsen Norman Group’s Wednesday User Testing Day (2005). We aimed for feedback on Wednesdays and Thursdays with a report out on Fridays. However, after a few weeks, the designers requested that we dial back. They found the weekly interval exhausting, partly because they needed more time to digest what they had learned so that they could iterate their designs, and partly because they were still getting used to the idea of showing designs that were still in progress. We dialed back to every other week until our design team grew to a point where we could ramp back up. Being open to change allows us to identify the cadence that best supports the team.
Mistakes are learning opportunities
No one ever gets their design right the first time. The same is true of research. One of us tried conducting weekly research sessions in a very ad-hoc manner, meaning complete seat-of-the-pants with no real planning. It didn’t take long to learn that this ad-hoc research delivered a lot of stress without delivering the needed insights. This mistake didn’t stop the research program—the researcher pivoted and put in place a planning process that ensured the research delivered actionable insights. Product team members respond to and learn from what doesn’t work. Researchers should do the same.
Scale Your Program
Introducing research to your team’s Agile product development process can provide you with the starting point for deeper engagement with your users. As you fine-tune your lean research process, start to think bigger and more strategically. Move beyond researching incremental improvements that can be delivered at the end of a sprint and look for opportunities to conduct research aimed at identifying and fleshing out the team’s longer-term “North Star” vision.
Ask for more
If we think of sprint-based feedback sessions as the minimum viable product (MVP) of a UX research program, that program can be iterated to introduce research methods that will inform plans for future releases. If you start by quickly delivering actionable insights through lean research, you’ll build credibility and trust with your team, and the stage is set to kick off deeper, more strategic research while maintaining a lean program that delivers more tactical, but impactful findings. For example, after building trust and delivering results for our teams, we broadened our scope to include a Kano study that helped prioritize features for the next release, as well as contextual research where we took members of the team into the field to watch users do their work and use the product in their natural environment. Buy-in for this deeper research would have been more difficult had we not delivered actionable insights through lean research in the preceding months.
Democratize research
Empower product team members to conduct their own research! If your lean program promotes close collaboration with team members, in time those team members should feel confident to conduct some research with help, if needed. A quick and easy win in this direction is to give your team access to unmoderated, asynchronous testing tools like UserTesting.com, along with guidelines for use and samples of effective test plans for different scenarios. Team members will need help understanding when to use tools of this sort, so give them examples of good test plans as well as problematic ones. Outline what not to test and what not to ask and why. Empowering teams to do research on well-defined task flows will allow them to quickly get the information that they need to move forward.
You could also help your teams to set up a “user advisory board,” a group of users that product team members can contact for brief phone calls or virtual meetings to gather feedback on design ideas. These users would provide the product team with a sounding board and, as a bonus, we’ve found that users enjoy participating because they feel special and heard. If you do set up an advisory board, be sure to outline rules of engagement to ensure that appropriate research questions are addressed and that users have a good experience.
If you’ve been brought in as a consultant to establish a lean research program, expect the program to wind down after your contract ends unless you give your product team strategies for continuing to engage with users on their own. Building repeatable programs that can live on in your absence or beyond your own tenure is a best practice in any organization.
Go Forth and Be Agile!
Incorporating UX research into an Agile product development environment is not always easy, but it is always worth it. You’ll build empathy for users, provide valuable, actionable insights at velocity, and your team will build a better product. So, get started. Aim high, gather feedback on what is and isn’t working, and pivot when needed. Give your research program the Agile treatment and you’ll continually improve!
