Effective retrospectives for UX Research teams
Learning from success and failure in user research
The typical week in the life of a UX Researcher is full of highs and lows.
One day, you might deliver a fantastic readout, feeling confident and well-prepared, with your findings well-received. The next day, you might face a disappointing call with stakeholders who decide to proceed without research, leaving you frustrated.
It’s easy to get caught up in these emotional swings without pausing to reflect on why things went well or poorly. But taking the time to analyze and understand both success and failure makes it possible to replicate positive results and avoid repeating mistakes.
This article will take a look at some of the common successes and failures that researchers often face on a team. We’ll explore retrospectives as a method to highlight these experiences so that we can learn from them. By documenting as you go, seeking diverse perspectives, and outlining next steps for improvement, you’ll gain tools for continuous improvement in both your individual career and your team’s development.
Where UXR teams succeed and fail
There are a few ways that any given research project can go “wrong.” Common mistakes include using an unsound study design or methodology, making errors during analysis and synthesis, or failing to ‘replicate’ in the context that counts.
But our roles encompass much more than technical research — and we can face setbacks and challenges in those areas just as often, whether failing to make an impact, mishandling relationships with stakeholders, or communicating our ideas ineffectively. We may execute a flawless project, but if it fails to persuade our stakeholders or produce meaningful change in the product, it’s worth pausing and asking what we could have done differently.
Taking a step further back, a mistake might involve the broader team. In other words, it might not be one’s responsibility as an individual contributor, but the byproduct of an inefficient process or procedure. If you discover, for example, that a cumbersome intake form is making stakeholders hesitant to reach out, there should be a mechanism for resolving the problem as a team.
Team leaders can also consider strategic errors, such as investing time and effort on work streams that became deprioritized, misallocating resources across projects, or failing to staff appropriately.
On the other hand, we have a tendency to assume that getting it right is the “default” state. That means we might take success for granted and overlook it. But these are instances we should aim to understand, repeat, and build upon. For example, overcoming a one-off logistical challenge or employing an effective technique to manage a difficult stakeholder could have transformative lessons for future projects.
Whether positive or negative, these experiences present an opportunity to reflect, learn, and improve.
Fostering a reflective culture
Creating an environment conducive to reflection requires a few table-stakes qualities.
First, cultivate a feedback-positive culture where feedback is common, expected, and valued. Second, establish (as much as possible) a safe space for open and honest communication, where negative or constructive feedback is seen not as an attack or sign of weakness but as a necessary step towards improvement. Third, encourage the willingness to occasionally step back from daily demands and look at the big picture, despite the constant pull of urgent tasks.
We may explore practical ways of doing all three more deeply in a future article — but periodically conducting retrospectives, or “retros,” is one useful tool that ties these qualities together and points teams towards improvement.
Retros are systematic, collaborative sessions typically held at the end of significant milestones, such as research projects or a series of related projects. They can also be integrated into annual or quarterly performance reviews or planning sessions. While focusing on a specific line of research keeps discussions targeted, quarterly retros can encompass a broader scope, including multiple projects and team processes.
Setting the stage for a retro
Preparing for any retrospective begins with gathering data from various sources, such as email inboxes, file drives, calendars, and project management tools like Trello or Monday. Consider including other tools relevant to your team’s specific practices. For instance, time-tracking tools like Toggl may help show the time typically spent on different stages of a project.
This data collection is a good start, but can easily become time-consuming or yield only superficial insights without a systematic approach. To streamline the process, consider regularly synthesizing and documenting the kind of information you’ll want to discuss as a part of your ordinary duties.
One practical method is writing a weekly reflection, or weeknote, typically on Fridays. Weeknotes can highlight accomplishments and pivotal events that might otherwise be forgotten in the course of a week. Team leaders can write weeknotes for their teams, or team members might contribute jointly, offering multiple viewpoints.
Each team member should prepare independently for the retro so that their individual perspectives can be better reflected in the conversation. Team leaders might, for example, identify connections between projects and stakeholders, while an individual contributor might focus on bottlenecks causing pain points across projects.
Additionally, consider assigning “homework” to attendees. Sharing an agenda and discussion topics in advance allows participants to think about their talking points and questions. You might also suggest brainstorming on a specific prompt, or provide an opportunity for anonymous feedback.
Effective retro frameworks
Here are a few tried-and-true frameworks for structuring your retrospective:
Post-mortem: This all-purpose framework can be used to look back on projects or time periods of virtually any scope. It takes a close look at (a) what went wrong, (b) what went well, and (c) how things could be improved in the future. After gathering information, the team discusses and documents it, then creates action items for implementation.
After-Action Review (AAR): Targeted more towards specific activities or events, AARs are useful after challenging tasks such as a difficult participant recruit or complex data collection protocol. Originally developed in the US Army, they provide focused feedback and action points.
Start, Stop, Continue: This framework uses a stoplight metaphor: red for stop, yellow for continue, and green for start. It’s especially useful for reviewing broader scopes, such as activities across a larger engagement or quarter, highlighting what is working well (to continue), what doesn’t (and should be stopped), and identifying new ideas or initiatives (to start).
The 4Ls: Flexible and memorable, the 4Ls stand for Liked/Loved, Lacked, Learned, and Longed For. It highlights successes (Liked), identifies shortcomings (Lacked), focuses on team and individual growth (Learned), and envisions an ideal future state (Longed For). One quicker variation, the 3Ls Retro, omits the Longed For dimension.
If these frameworks don’t fit your needs, there are many other structures that have been successful in different situations. Over time, occasionally using different frameworks helps to keep the retros fresh and avoid staleness.
From reflection to action
Conducting a retro is only a first step. Putting the lessons learned into practice is what ultimately makes the effort worthwhile.
To make sure that action is taken, set aside time at the end of each retro to explicitly ask the team: based on what we’ve discussed, what needs to be done? Identify the open tasks or actions required from the conversation. Determine dates when they should be started or completed, and assign responsibility for each task. If needed, clarify where these tasks will “live” and how they will be shared with the broader team for visibility.
Since the participants in the next retro may not be the same as those in the present one, and memories often fade over time, maintaining an archival record and a source-of-truth summary document is vital. One simple step is to record the session using your conferencing software and keep the link accessible wherever retro materials are stored. For another layer of depth, consider transcribing the recorded session audio and processing it with a language model for summarization. Tools like Fathom1 offer these capabilities for free.
Scheduling a specific time to revisit these learnings is also beneficial. Often, reviewing the previous retro can become part of the preparation for the next one, creating a virtuous cycle of continuous improvement.
The bottom line
UX research roles are full of ups and downs. In this article, we’ve looked at a few of the common successes and failures UX Researchers face in their day-to-day roles. But more important than these specific highs and lows is retracing your steps to understand how you got there.
To that end, we’ve examined using retrospectives on your team. A few key takeaways:
Create an environment conducive to open and honest communication. Take responsibility for failures and be willing to learn from them. But also acknowledge the things that went right, which may often be taken for granted.
Ensure each participant in the team retro prepares appropriately, reviewing any available data—whether project files, communications, or metadata like calendar time. We emphasized the importance of documenting as you go, using tools like weeknotes.
Consider different lenses for your retro, whether a standard Post-mortem, a more targeted After Action Review, or popular variants like Start, Stop, Continue or the 4Ls retro.
Document the retro’s discussion and summarize it for posterity. At a minimum, list the open action items to make the lessons of the retro actionable, assigning deadlines and responsible parties.
The key benefit of performing a retro is to make successes and failures visible so that you can understand their causes and make them repeatable. Bringing diverse perspectives into this process and fostering an environment of open communication enriches the practice. And structuring the retro makes it easier to conduct and revisit over time.
In short, the retro is a powerful tool for continuous improvement, both for individual researchers and teams.
If you’re not already conducting retros, sharing this article with your team might be a great way to start the conversation and get one on the calendar. You can also lay the groundwork by consolidating necessary documentation in one place or by writing weekly reflections in weeknotes. And if you’re already conducting regular retros, we hope the advice and frameworks suggested here offer new avenues for exploration and help deepen your practice.
Drill deeper…
Depth is produced by Drill Bit Labs, a consulting firm on a mission to advance the field of user research. We partner with leaders in UX and digital product development through research projects, education and training, and strategic advisory support.
These services help make all our free industry reports and content possible. We’d be happy to open a conversation to discuss your specific needs and goals for this year.
From the archives
This Fathom referral link grants new users 3 months of Premium access for free, but doesn’t convey any benefit to us as referrers. Enjoy!