In the last series, we discussed the logistics of running and analyzing UX research sessions. In this final post, we’ll discuss how to keep research findings from getting lost over time.

All things, even the best built machines, need maintenance. The same is true for UX teams; especially when it comes to incorporating research findings into an agile process. The following tips will help you keep up the much needed maintenance to avoid your hard won research getting lost in the flow, and to keep the process flowing smoothly.

Keep your UX research findings from getting lost over time with these tipsClick To Tweet
Learn together

As mentioned in the previous piece, relying on team collaboration can allow you to shift your focus away from creating lengthy summary documents. You will still need some way to keep track of everything you’ve researched, however, in case team members shift, priorities change, or you simply don’t have time to address all your findings. Plus, you need ways to document what you’ve done for posterity’s sake or in case there is a stakeholder or a team member that couldn’t be involved.

Keep everyone in the loop

As soon as the research debriefs are over, I like to send out a summary email to the team that highlights what the key research question was, what we found, and what we’re planning to do next. Simple, to the point, and the same format every time so people know what to look for. If there was any sketching or other visual brainstorming from the debrief session, include photos and brief explanations. The key here is to be brief, both for readers and for yourself; aim for the summary to take no more than 15 minutes to write and 5 minutes to read. If the team has a wiki or other shared note resource for things like retrospective notes, keep an ongoing summary and just copy and paste the email.

Mind the backlog

Next, add your suggestions to whatever mechanism you use to keep track of future work. Most Agile methodologies (e.g. Scrum, XP, Kanban, etc.) call for the use of some version of a backlog, or repository of user stories that describe needed features, changes, or other work to be done. Rather than creating a separate UX backlog for things that improve the experience – add those stories to the overall backlog to ensure that they are visible to the whole team and get prioritized along with other types of work. This will reinforce the importance of focusing on people’s experience and the importance of including the whole team in those efforts.

UX spike

If it becomes clear that you have a large amount of work to be done to figure out UX solutions, you can consider having a UX spike. A spike is just a focused iteration where you the whole team focuses on only one type of story, whether it’s tackling bugs, understanding a technology, or brainstorming design solutions. The key difference between a spike and a normal sprint is that you end the spike being better informed but not necessarily with working or releasable code.

Team retrospectives

You can also utilize the Agile practice of having team retrospectives to keep UX research findings top of mind. In a retrospective, the team meets to discuss the work cycle that was just done and what could be done better from a process and team perspective moving forward. You can take a small amount of this time to review and discuss the research that was just done or to update the team on UX metrics you monitor over time. That way, you ensure that users’ goals and needs stay top of mind and the team can shift as it needs to in order to keep improving. If your team has a wiki or other tool that they use to keep track of retrospective outcomes, you can add a line or two for a UX summary so things aren’t lost.

Agile UX Success

In summary, the whole Agile team will need to adjust to successfully incorporate UX research well into the process. There is no one solution that will fit for every team, but try the above tips to get yourself in the right direction. Please reach out if you have any questions or have had the opportunity to implement other tactics that have worked well!