Incorporating Agile UX Research: Part 1 – Setup
Incorporating research remains one of the biggest issues for UX teams operating in the world of Agile.
Not just incorporating the research, either, but incorporating it well. I’ve seen lots of people share their tips to coordinate design and development efforts and create ever leaner and faster design documents, but user research remains an area of struggle for most teams. Even if teams are able to figure out how to fit research into sprints, making sure the data collected gets appropriately analyzed and then actually used can still be troublesome.Teams fitting research into sprints still need to make sure data collected gets appropriately analyzedClick To Tweet
In this series, we’ll discuss challenges of integrating UX research well and some strategies to overcome those struggles.
Quick recap of Agile, since it’s one of those terms that is everywhere but gets misinterpreted often: Agile is a software development approach. There isn’t a specific process prescribed, but the approach has a shared set of values and principles that speaks to how the teams operate and organize work. Agile teams are supposed to focus on launching small chunks of working code often, foster collaboration between and among users and cross-functional teams, and have an openness to flex plans and processes as new information is learned. There aren’t distinct periods for discovery and definition, design, development, and testing. Rather, the team is to be constantly learning, adapting, and building. A lot of Agile teams used a framework called Scrum with well-defined, timeboxed chunks of time called sprints to plan and do increments of work.
In theory, this lends itself perfectly to performing and incorporating UX research. Iterative cycles of building and learning? Focus on responding to items learned over time? Heck yes!
But in practice, Agile teams often struggle with keeping up with the pace of research. How do you make sure you have something to research every single cycle? How do you analyze all the data you collect quickly? And how on earth do you keep dev teams on track with a constant influx of information?
The truth is, there is no magic answer. As with much of the rest of UX, the best solution depends on context. How big is your team? Who’s on it? What are you working on?
Read on to hear about ways to shift practices to make the most of UX research in an Agile setting.
There are tons of ongoing debates about both “ideal” Agile team makeups and the extents to which a UXer’s skills should go. Should Agile teams have embedded UXers or should there be a separate team of cross functional UX professionals? If there’s a UXer on a team with developers, should that person do research, low and high fidelity design, maybe even code?
I’m not here to rehash that debate or pick sides, but the scope of a UXer’s role on an Agile team matters when it comes to incorporating research for two major reasons: UX is really hard on your own, and you shouldn’t be the one testing your own designs.UX is really hard on your own, and you shouldn’t be the one testing your own designsClick To Tweet
The best solution is probably going to differ from place to place, but there are a few scenarios I’ve seen work quite well:
- Embed a full time designer and researcher on each cross-functional team. The two can crossover skills to some degree and collaborate on sketches, prototypes, and actually running research, but there is some separation of who owns visuals and who owns research. This setup is really awesome, but I’ve only been in a few organizations that had the budget to pull this off.
- A more realistic option is to have a full time designer on each Agile team and a research unit that floats between Agile teams. Researchers can and still should collaborate with designers, they will just have to divide their attention between teams. Usual pros and cons of splitting attention apply.
- I’m not generally in favor of attempting to hire UX Unicorns, but I have seen a few generalist set ups work quite well in Agile. The key for success in this case is to have one generalist UXer on each cross functional team, and then have the generalists partner up to research each other’s work, especially when it comes to usability testing. This helps make sure you don’t introduce the unavoidable bias of testing your own work (e.g. how much do you love option A that I lovingly crafted and how much do you hate option B my PO forced on me?) Sometimes you just can’t afford a research specialist who is trained to remain neutral, but partnering will certainly work better than testing one’s own work.
There are many more set ups that can work, but given the option, I’d go with number 1 above.
In traditional development processes, there’s an entire phase dedicated to figuring out what you need to figure out. You might get weeks or months for discovery, with plenty of time to design just the right study and include a lot of participants. All that’s great, but it’s not realistic in Agile. Instead, you are constantly learning, designing, building, and launching. Most teams use some version of a sprint to timebox efforts, and these sprints are usually 2-3 weeks long, which means that UX research efforts are now supposed to be planned, executed, and analyzed in that time. Even without the scrum framework, there is the push to get feedback faster and faster and the dedicated time to research is gone.
So how to figure out what questions to ask and how to answer them? The good news is that all the same rules of UX research considerations apply in Agile. Once you figure out your research goal, the same methods you’d traditionally use will still apply. Christian Rohrer and Jeff Sauro both have a good cheat sheets if you need help with that.
However, you’ll probably have to adapt the methods to fit the time frame. My first suggestion is to break down your research goals into the smallest possible questions and create specific hypotheses to explore. Investigating a single question at a time will allow you to narrow the scope of your study, which in turn makes planning, running and analyzing all faster. You might even be able to combine two narrow goals into a single session. For instance, maybe you’ll follow up on a benchmark for an existing interaction and then do a single task tree test. The key is to maximize the time you have with participants to answer the most pressing questions at the time.Maximize the time you have with participants to answer the most pressing questions at the timeClick To Tweet
You’ll also want to consider if you can relax some of your traditional standards for research. No, you don’t want to ask the developers on your team to be usability test participants, but maybe you can find representative-enough users in your sales department or pay for close-enough users from a survey service. Maybe you can get away with talking to 4 people instead of the 8 or 10 you’d like. The key is to get enough information to be useful without losing the integrity of your research efforts.
You may also want to look into relying more on remote, unmoderated, and automatic methods. There are things that are better suited for in person or moderated, but you can still get great insights and the turnaround time can often be very quick. It’s especially helpful if you have a spread out user base that operates in different time zones.
Remember – the beauty of constantly doing research is that you always have another opportunity to get clarify or ask more questions. You can find more on adapting research methods to Agile processes here.
In the next article, we’ll discuss some of the tactical logistics of conducting ongoing UX research in an Agile environment.
Amanda 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 for businesses large and small. She has focused most of the last decade focused on finding innovative ways to understand end users 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. She has a human factors background and an engineering degree from Tufts University.