These days, everyone is into speed. How fast can we conduct research? How quickly can we get this new feature out to users? What are ways we can optimize processes to make them faster?
Speed is no stranger to user researchers. Many companies work in an agile or agile-adjacent environment where the team timeboxes their work into two-week sprints. This environment generally means research always needs to be ahead of schedule, which can be challenging—especially with poor communication or planning.
However, many of us work in this type of environment. When working on two-week sprints or similar frameworks, how do we ensure user research is part of the process?
Four phases of research
Before we try to fit a square peg into a round hole, we must define the different types of user research. Once we clearly define our research categories for ourselves and others, we can see how they fit into the team’s timeframes and cadences.
I split my research into four different phases or categories:
Strategic research encompasses generative research or problem-definition research that can help shape the company’s vision, goals, and innovation. Through this research, you can also better understand your user’s through deliverables such as personas, journey maps, or mental models. Ideally, you take on strategic research on overarching questions teams have once a quarter. These topics are typically spread across multiple teams and can impact the entire organization. Strategic research projects can take six to eight weeks.
Concept research helps ensure that teams are heading in the right direction with early ideas. You can show participants sketches of a concept or ask them to talk about a particular concept or idea. This type of research is lower in the funnel than strategic research. It can help teams prioritize what to work on next and help them create an experience aligned with the user’s mental models. Concept research can take up to four to six weeks.
Evaluative research is about evaluating designs (namely prototypes) that help prove or disprove any assumptions and gathering feedback on initial designs and flows. This type of research can help uncover usability or accessibility issues and help the team understand if they are going in the right direction with specific designs. Evaluative research projects can take two to four weeks to complete.
Maintenance research is all about monitoring and acting on ongoing feedback from users to measure the impact of the launched solutions. At the beginning of your study, you should aim to set up success criteria/metrics to show how successful or impactful the project was. During this research phase, you are taking in continuous feedback to see if additional research is needed. Maintenance research is ongoing but should be studied particularly two to four weeks after launch.
Now that we have defined our research categories and timelines, we can better understand how these fit into the agile setup.
Planning strategic research
You should aim for one major strategic study per quarter (two, if you can!). This research occurs across all the sprints and is not tied to one particular sprint. Here are the steps for planning out this type of research:
At the beginning of the quarter, hold a question-gathering workshop. In this workshop, gather all the questions teams have about users, inside and outside your product
Once you have a list of all the questions, put together similar ideas and present this list to the group in an impact x effort matrix. In this matrix, you will plot the finalized list of topics according to how impactful each is to the organization and user and how much effort each topic will take you (e.g. time to recruit niche participants)
Once you finalize the matrix, pick the most impactful and least effort projects. The rest will go into a backlog
If you already have backlogged topics in the next quarter, make sure to reprioritize them in case anything has changed
Planning concept research
Concept research is one of the types of research that requires a lot of foresight and planning.
As I mentioned, these projects can take four to six weeks to complete and are typically tied to sprints. That means, if your team is working on two-week sprints, you need to know at least four weeks before research is “due” to have it ready in time. Here are the ways to plan for concept research:
At the beginning of each quarter, review the team’s backlog to see any viable projects for concept research. Put these projects in your backlog and make sure to start them four to six weeks before the sprint
Meet weekly with your teams to review the backlog and upcoming projects to ensure nothing has changed
Consider a monthly rolling research program to have a constant space set up for concept tests
For last-minute concept tests, consider unmoderated approaches or a quantitative method, such as surveys
If your team can’t or doesn’t plan far enough ahead, it’s okay. In this case, you can incorporate strategic research and evaluative research instead of concept research. In between studies, take the time to educate teams on concept research and how it can benefit them to plan for this kind of research.
Planning evaluative research
Since you can conduct evaluative research quickly (two to four weeks), it is the most popular type of research to incorporate into an agile environment.
If you have never done user research in an agile framework, I recommend starting here.
Evaluative research is always tied to a sprint because you evaluate a design that your team will implement (fully or partially) during the next sprint. Since you can do evaluative research in two weeks, that means you have to be two weeks ahead of each sprint necessitating evaluative research. For example, if the team will develop a feature in sprint two, you need to start researching that feature during sprint one.
Here is how you can plan evaluative research:
Like the above, at the beginning of each quarter, review the team’s backlog to see viable projects for evaluative research. Put these projects in your backlog and make sure to start research two to four weeks before the sprint
Meet weekly with your designer(s) to see upcoming work they need to have tested. Align this with the projects you identified at the beginning of the quarter and put it into your backlog
Meet weekly with your product manager (it can be the same meeting) to discuss any changes or upcoming projects that need evaluative research
If presented with last-minute evaluative research, consider an unmoderated approach that can run over a weekend and deliver faster results.
Technically, you can also conduct evaluative research during the first week of a sprint. This concept is similar to design sprints, where you create a prototype (based on previous research), test it, deliver results, and iterate all in five days. While you can do this, it takes a lot of coordination, and I always recommend doing as much evaluative research before the sprint.
Planning maintenance research
Ongoing maintenance research should ensure that anything the team launched aligns with the user’s needs and expectations. This is how I plan and continue to work with maintenance research:
Define success criteria and metrics for a project upfront. If you don’t feel comfortable doing this on your own, meet with a product manager and/or data/product analyst to help you
Before launch, meet with your product manager and/or data/product analyst to set up ways you will measure the success criteria. Some widespread feedback measurements include reviews, comments, customer support tickets, A/B tests, or satisfaction surveys
For two to four weeks after launch, keep a close eye on the defined measurements. If something needs more attention or research, flag it to the team to discuss in the following sprint.
Adapting user research to agile
When thinking about adapting user research to an agile framework, we need to do as much as possible to make the two compatible. Here are some additional ways to make user research successful in this environment:
Create a research roadmap and backlog for visibility of your work and to help align with product roadmaps
Timebox your work into similar chunks within sprints. For example, recruitment takes two days, planning takes three days, and conducting takes three days.
Have one or two days of a sprint be research days where for half the day, team members are present in research sessions
Deliver concise reports that allow stakeholders to ingest information effectively and efficiently (video clips!)
Consider starting a participant panel to make the time-intensive process of recruitment easier, enabling you to conduct research on a shorter timeline
How do you conduct user research in an agile workplace? Come continue the discussion in our 2000+ strong Slack community.
Written by Nikki Anderson, User Research Lead & Instructor. Nikki is a User Research Lead and Instructor with over eight years of experience. She has worked in all different sizes of companies, ranging from a tiny start-up called ALICE to large corporation Zalando, and also as a freelancer. During this time, she has led a diverse range of end-to-end research projects across the world, specializing in generative user research. Nikki also owns her own company, User Research Academy, a community and education platform designed to help people get into the field of user research, or learn more about how user research impacts their current role. User Research Academy hosts online classes, content, as well as personalized mentorship opportunities with Nikki. She is extremely passionate about teaching and supporting others throughout their journey in user research. To spread the word of research and help others transition and grow in the field, she writes as a writer at dscout and Dovetail. Outside of the world of user research, you can find Nikki (happily) surrounded by animals, including her dog and two cats, reading on her Kindle, playing old-school video games like Pokemon and World of Warcraft, and writing fiction novels.
Art by Ben Jomo, illustrator.