When we first tried an Agile development process, it was directly at odds with our UX research process. While the development and design teams were running full speed ahead on Agile sprints, UX research only came in toward the end—almost as an afterthought—to validate questions that the team already thought they had the answer to.
This led to a variety of problems:
- UX research studies were too narrowly scoped to answer important questions
- Research results came too late in the cycle to effectively invoke change in the product
- The development and design team kept building features that weren’t aligned with user insights, and hence, weren’t solving any important user issues
After evaluation and collaboration with the team, we revamped the Agile process with the intent to solve these problems with the process. An updated Agile process resulted in having UX research play a fundamental part in the beginning of an Agile sprint to help align the team on what user problems they would solve. UX research also helped at the end of a cycle to validate whether the features built during the sprint solved the intended user problems. The outcome of this change was that the products we shipped made a much more positive impact on users.
Here is a before and after visual depiction of the process change:
I hope that more people can learn from the changes we made with Agile and UX design, so here is a step-by-step walkthrough of the phases in the improved Agile cycle.
Kickoff and Team Alignment
Before starting the Agile sprint, align with your fellow designers, engineers, and product folks on what the objective of the sprint is. Are you trying to improve new user adoption or increase the percentage of users that are retained? What are the biggest questions the team has about the users and product that would help guide you toward achieving your objective?
Run a workshop with every person involved to gather their sprint objectives and questions they have about users. I recommend having a specific set of prompts for the team and having each member use sticky notes to write their thoughts out individually.
Example prompts for your team:
- What do you hope to accomplish in this sprint?
- Which users are you hoping to impact with this sprint? (This could be new users, current users, or someone else. The more specific you can be, the better.)
- What do you wish you knew about your users that would help you with this sprint?
- What questions do you have about the users you are targeting?
- What would you change or do after learning the answers to your questions about your users?
Have each member of your team individually write their answers to the prompts on sticky notes. Once everybody is done, have them post their notes on the wall or an area where everyone can see. Have each team member read their notes aloud as they put them up.
Then, as a team, group the notes into sets of similar contents. Label the sets, and these labels become the themes that you’ll use for guiding your first phase of research.
Conduct Foundational Research to Guide the Sprint
Now that you have identified themes from the team alignment kickoff, you can break them into the overarching questions your team has and plan a foundational research study to find answers.
This is where using immersive methods like contextual inquiry or in depth one-on-one interviews could be a good option, depending on what your questions are. The idea is to gain context and depth around the team’s questions and find insights that can help guide whatever they will end up building in their sprint.
A few examples of foundational research methods:
- In-depth one-on-one interviews. Set up 30-minute interviews with the users that you’re hoping to impact with this sprint. These can be in person or remote. Gather background information such as their motivations, what their biggest challenges are, and on their day-to-day experiences. Then ask questions pertaining to the themes that your team identified.
- Contextual inquiry. Go to the place where your target users either work or live to observe and gather information about their surroundings and environment. Have a set of guided questions related to the themes and ask your users while they’re in their own familiar environment.
The results from this phase of research will become the foundation for all the feature work that comes out of the agile sprint.
Use Research Results to Inform Design and Development
After you’ve conducted and analyzed results of the foundational study, your objective should be to ensure that the research is utilized by the team to inform what’s being designed and developed for the Agile sprint. You’ll need to give everyone on the team an opportunity to digest and understand the results of the research. Your priority is to gain exposure for your research and make sure everyone is armed with the insights that you’ve discovered.
A few examples of how to broadcast your research results:
- Conduct a research share-out and Q&A session. Send results from your research ahead of time, then gather your team for a Q&A. Ideally, the team has read the results ahead of time. If not, recap the results on the spot, then ask if people have questions or reactions from the research. Having an engaging discussion is a great way to let the results sink in.
- Create summary printouts of your research and post them around the office. It’s best if you make these printouts visually appealing and engaging. Print them out and paste them in the bathroom stalls, by the coffee machine, or anywhere in your office people may idle and have time to read. This is a great way to provide exposure to the research in an informal way.
- Conduct an interactive gallery style workshop. Print your research results on large posters and display them around a meeting space. Have your team gather around and walk through it like they’re in a museum gallery. Have each person record their reactions and questions on sticky notes and paste them directly to your research posters. As a group, go over the reactions and questions together.
Conduct an Evaluation Study
As the design and development teams are building the solutions for the sprint based off results of the foundational research, get a head start and begin planning an evaluation study. This differs from the previous discovery study because its intent is to evaluate whether what the team has built addresses the problems that were identified in the discovery phase.
A few examples of evaluation research methods:
- Concept testing one-on-one interviews. Show concepts or working prototypes to users and probe them with questions to gauge their responses. Assess whether they think these concepts will solve their problems.
- Observational study. Recruit a few users to try the feature. Observe their behaviors and assess whether the goal of the feature has been achieved.
- Post-usage one-on-one interviews. Look at behavioral data from the feature and recruit target users (both people who exhibit the behavior you want and those who don’t). Compare what the experience has been for people who used the feature versus those who didn’t in order to understand the gaps in your team’s solution.
After conducting the evaluation study, make sure you take steps similar to those you performed after the discovery phase. Ensure that your team has had exposure and access to the results of the validation study and have a chance to digest the learnings.
End of Sprint Reflection
Now that your team has completed the sprint and you’ve run an evaluation study, it’s time to reflect on the outcome and develop a game plan for the next cycle of the sprint.
If you met the objective of your sprint and solved the problem for the users you were targeting, congratulations, it was a successful sprint! Your team now has confidence and evidence that they accomplished what they set out to do.
If you did not meet the sprint objective or you found additional problems in the solutions you built, that’s alright. This is where the value of Agile and UX research working together becomes truly beneficial. Gather a list of what the issues were and use it as a foundational basis for your next sprint cycle. Start from the beginning again with another kickoff and team alignment to refine your questions and embark on the next cycle of your sprint.
In Conclusion
I hope that you’ll find this process useful in trying to implement UX research effectively in an Agile cycle. The key idea is to ensure that every action taken during the Agile process is aligned with the sprint objective and with solving a specific problem for the user. UX research is also there to continually evaluate and assess whether the outcome that the team has produced is successful. By implementing this strategy, you’ll have UX research embedded from the beginning to the end of the Agile process and empower your team to solve user problems with more alignment and feedback on their work’s impact.
