User Research Retrospectives: Your Key to Running Smoother Studies

I recently ran my first research study in a new position. It was a much different process than I expected.

In the past, as a solo researcher, I was used to being embedded in different teams. However, in my new role, we operate much more like a service to a large organization. 

I used to be able to be part of a team's retrospective, where I could bring my thoughts on the project to the table. But here, in my new role, we sent out a stakeholder satisfaction survey, instead—which felt much more passive. 

When I started missing retrospectives, I felt that I started missing out on loads of valuable feedback. And this feeling was shared with my colleagues; as researchers, we wanted more targeted feedback on how we could improve individually and as a team.

What is a retrospective?

Retrospectives are a common occurrence in the world of agile product organizations. This ritual allows teams to look back on the work they did during a project, and comment on how it went.

Generally, this activity includes everyone who was part of the project and aims to understand what went well and could be improved. However, I have found these retrospectives focus on the actual "doing" of the project—development time, development blockers, and communication errors. Retrospectives usually do not encompass the "before" of the project, where user research often lies.

While this type of retrospective may work for some researchers embedded in teams, it doesn't always mean you will get tangible feedback. Some of your colleagues in the retrospective may not even be able to give you feedback as they weren't part of the research process. The standard product retrospective may not provide you with what you need to improve.

Enter: the user research project retrospective.

What is a user research project retrospective?

This retrospective type is narrower in scope and focuses on the user research portion of the project. It only involves the relevant stakeholders, which makes it easier to find a time, and also shorter.

The goal of the meeting will be to understand:

1. What went well with the user research
2. What didn't go well with the research
3. What you could do better next time

The retrospective gives stakeholders a space to explain how they felt and why which allows you to dig deeper than the survey.

Of course, having a good relationship with the stakeholders is critical and gets them to share more. If this is not the case, consider having a colleague, such as another researcher, run the session.

Why retrospectives are important as a user researcher

As a user researcher, you need to get direct feedback to improve your craft.

You don't have the luxury of getting customer feedback on your designs, how a team performed via a burndown chart or someone to look over your code before it goes live. User research lives in the background, so it can be difficult to get input on improvements.

The user research project retrospective can get you the feedback and information that helps you improve your skills. Gathering this feedback, especially from stakeholders (product managers, designers), is essential in moving up in a research career.

As you look towards senior or leadership roles, stakeholder management is a foundational skill. This retrospective can surface concrete improvements and next steps for you and your team.

How to run a user research project retrospective

You can run a user research project retrospective at two points:

1. After an entire project finishes
2. After the research portion of a project finishes

There are pros/cons to both. Sometimes, if you wait until the end of the project, people forget key events or feedback they wanted to give.

However, at times, user research is used until the very end of the project, so you wouldn't get a full spectrum of feedback if you did it directly after the sessions.

Ultimately, it is up to you and the way your team/organization works.

Ideally, there will only be no more than eight people involved as it can get difficult to manage many people in one meeting

With four people, about 30-45 minutes should be okay, any more than four, and I recommend booking an hour. This walk-through will give the timings for a 45-minute retro.

*Note: Although retrospectives are conducted in-person and with post-its on board, many teams are still remote. This guide will walk you through a remote retrospective, but the same principles still apply in-person.

Step 1: Invite your stakeholders

Invite the most relevant stakeholder to the meeting. These stakeholders are the ones who were a part of the research from end-to-end. They requested the research, observed sessions, took notes, and were part of the analysis.

If there aren't stakeholders involved in the entire process, invite those who participated in the majority.

Step 2: Prepare your board

Create a virtual board on tools such as Miro, Mural, Google slides, or Excel.

Write the following sections:

• What did we do well? (Continue)
• What didn't go well? (Stop)
• What could we do better? (Start)
• Next steps

Step 3: Begin the meeting (5 minutes)

Welcome everyone to the retrospective meeting and establish any ground rules.

• Don't take anything personally
• "Yes and..." Everyone is entitled to their thoughts and perceptions; we are here to understand them
• Which specific research project and timeline this feedback should cover
• Stay away from blame and, instead, highlight improvements for next time

Step 4: What went well (10 minutes)

Have each team member use green sticky notes to write down what went well during the project. There should be one idea per sticky.

As people post their stickies on the whiteboard, group similar or duplicate ideas. Take five minutes to do this individually, and then five minutes to discuss the ideas together.

Step 5: What didn't go well (10 minutes)

Have each team member use pink sticky notes to write down what they feel did not go well. There should be one idea per sticky—group similar or duplicate ideas during this portion.

Remind the attendees that this is not about specific people, but about outcomes or actions that did not go well. Take five minutes to do this individually and then five minutes to discuss them together.

Step 6: What could be done better (10 minutes)

Have each team member use blue sticky notes to write down what could be done better next time. There should be one idea per sticky—group similar or duplicate ideas during this portion.

Take five minutes to do this individually, and then five minutes to discuss them together.

Step 7: Next steps (10 minutes)

Going back to the "stop and start" columns, have the team use purple stickies to identify concrete actions to improve or start the ideas on the board.

I recommend taking a few minutes during this time for the team to assign an owner and timeline. If you have a lot of improvements or action items, you can also use this time to vote on the top issues.

What to do with the feedback

After the retro, there are a few ways you can reflect and use the valuable feedback given to you:

• Self-reflect. Take the time after the retrospective to write what you learned and any action items for you to take on. Also, make notes on how you can improve your research craft. Again, set a timeline for these items so that you follow-up.
• Report back to the research team. If you are working with other researchers, go back to the team, and present the findings. Focus specifically on processes or ideas that impact how the broader team works. Create any action items for how the overall team could improve, assign owners, and note timelines.
• Always follow-up. The worst thing to do is holding a meeting where people share their feelings and then not following-up on important outcomes. Even if you fell behind on a deadline, or weren't able to make a change, let your stakeholders know. Trust me, they will appreciate it.

Overall, user research project retrospectives can give you and your team great insight on how to improve. We have gathered excellent outcomes that have positively impacted how we work and have changed our stakeholders' experience.