Reflecting on your work and work processes is a key component to growing as a designer. Creating a formal process for that reflection can help ensure it happens on a consistent basis, and doesn’t get lost in the shuffle of everyday work.

A design retrospective presents an excellent framework for introspection, whether you work on a design team or as a solo designer.

What is a design retrospective?

Retrospectives, also referred to as retros, come from the world of Agile development and the Scrum system (for those not familiar with Scrum, it’s a project management system that emphasizes teamwork and iterative progress toward a goal, usually broken down into sprints). In a traditional Scrum retrospective, at the end of each sprint cycle the entire design team comes together to reflect on what worked and what didn’t, and make plans for future improvements.

A Scrum retrospective generally has four parts:

1. Setting the stage

2. Reviewing what went well

3. Assessing what needs to be improved

4. Coming up with next steps

These steps provide a structure for reflecting on a project and creating an actionable plan to improve the next project.

During each part of the retro, activities are often used to help the team better share their knowledge in a fun or interactive way. In most cases, everyone is invited to participate simultaneously by writing down feedback on sticky notes or on a virtual whiteboard, for example. This is especially useful when sharing feedback on what needs improvement. If everyone is writing down their thoughts at the same time, they don’t have time to overthink what they’re sharing and are more likely to be straightforward about their feedback.

How often to run a retrospective

In Scrum, retrospectives are generally conducted at the end of each “sprint”—a set period of time in which specific tasks are completed (sprints generally last 1-2 weeks, though may be longer). That means they may be occurring during the middle of an actual project. On larger projects, you might have multiple retrospectives before the product is completed.

Even if your team isn’t working within the Agile/Scrum framework, you should still run retrospectives for each project. Reflecting on the work you’ve completed and how you’ve completed it sets your team up for improvement.

Designers and design teams who adopt a growth mindset can find the retro process to be a vital step toward development.

If you’re not working in sprints, the frequency of your design retrospectives depends largely on the project. Smaller projects might only need retrospectives done at the end, once the product has been launched. However, heftier projects can benefit from more frequent retros, carried out after reaching each major milestone. This allows for iterative improvements throughout the project, creating better work along the way.

For larger projects, there are four main points at which you should consider running a retrospective: at the end of the discovery phase, at the end of the prototyping stage, when the first functional product is created, and once feedback has been received and acted upon. These are good functional milestones for retros because they’re natural turning points in a project. Having a retrospective in the middle of any of these phases can actually derail the project or slow down momentum.

Breaking down the four stages of a design retrospective

If you’re running a design retrospective, there are a few key phases you’ll want to go through with your team.

1. Set the stage

Setting the stage in a retrospective can be one of the most important steps. This is where the person leading the retrospective (the Scrum master in the case of Agile) sets the tone for the rest of the meeting. They should also remind everyone of the goal of the retrospective: to embrace an improvement mindset and help the team create better work going forward.

As the facilitator in a retrospective, it’s your responsibility to make sure that all team members feel like their opinions are heard and valued. It’s important to create a culture of growth. Remind participants that feedback should be constructive, whether it’s positive or negative. This is particularly important when going through the feedback for what needs improvement. If a project isn’t going well, this can quickly turn into a blame game. Participants should not take feedback personally (and should be careful not to make feedback personal). Facilitators are responsible for making sure that doesn’t happen.

2. Evaluate what went well

It’s important to focus on the positive during your retrospective. The facilitator should plan an activity that helps team members consider what went well during the project or sprint.

This is often the easiest part of a design retrospective. People generally like to talk about positive things. It’s easier than talking about the negatives of a project.

There are a few questions facilitators can try to find answers to during the retrospective to get the best insight into what went well.

What went according to plan? This is important to note, because it’s an indication of how well the team’s expectations met reality. If most things went as planned, then you know the plan was well thought-out and the process used to create it can be implemented again. If things didn’t go according to plan, it’s a good idea to reassess the plan itself, as well as the method used to come up with it, to see what can be improved.

Were any new systems successful? If your team tried out something new, assess whether it’s working or not and make a decision whether to continue using it or try something else.

What tools and techniques worked? Similar to trying new systems, if your team used any new tools or techniques, the retrospective is a perfect time to assess what’s working and what isn’t.

What did the team learn? The best designers adopt a growth mindset and constantly look to learn new things. Discussing what everyone learned helps reinforce those learnings and makes sure the entire team benefits.

What are the strengths of the design? While traditional retrospectives often focus on the team and workflow, it’s important for a design team to also look at the design itself. This is an excellent learning opportunity for the team to see where their strengths lie.

You don’t always have to evaluate the answers to every question above, but you can use them as a jumping-off point for how to structure this part of the retro.

Be sure to record all of the answers to these questions, so that you can refer back to them later on during the retro and after you’ve finished the process.

3. Evaluate what went poorly

While discussing what went well is vital to the retrospective process, evaluating what didn’t go so well is equally beneficial. Without diving into what went wrong, it’s hard to fix those things going forward.

It’s important for the facilitator to maintain certain standards during this portion of the retrospective. Talking about the negative aspects of a project can quickly devolve into personal attacks and blaming other teammates if allowed. Reminding participants to avoid personal attacks, and not to take criticism personally, is vital.

All criticism given during this section should be constructive. It should be given with the intention of making improvements, not just as a complaint. To that end, there are specific questions facilitators can ask to get constructive feedback from the team that’s less likely to cause conflict among team members.

What didn’t work? By focusing on whether something worked well or not, it keeps the focus on the process and not the people.

What should be done differently? Just because something technically worked, doesn’t mean it’s the optimal way to do it. Exploring different ways to accomplish project goals is a chance for the team to grow and problem-solve together.

What was lacking? Sometimes it’s the things that are missing that can cause the most problems on a project. Are there issues with communication? Lack of a clear approval process? Find out what people on your team are missing in the process or in the work itself and plan to brainstorm for solutions during the final part of the retrospective.

What about the design itself could have been improved? Just like looking at the strengths of a finished design, looking at where it falls short is also important. In some cases, the shortfalls might have been unavoidable due to client constraints or resources available. But in other cases, it might be a weakness on the team or in the workflow that caused issues. Was enough time spent on each part of the process? Were shortcuts taken or corners cut? Encourage the team to take an honest look at the design and figure out what could have been better.

Just like the positives, make sure to record all of the negatives your team comes up with. These will be important for crafting an action plan in the final part of the retrospective.

4. Make an action plan

A retrospective that doesn’t result in a plan of action for improvement moving forward is a waste of your entire team’s time. It’s important to take the feedback you collected in the previous parts and analyze what should be continued and what should be changed.

Once you’ve recorded all of the positive and negative feedback from the group, you’ll want to check it for duplicates or conflicts. If a lot of people are saying the same things, that should be an area of focus. If one person said a particular part of the process worked for them and someone else says the opposite, that warrants further discussion to figure out why that piece is viewed so differently.

Your action plan should include things to continue doing, things to stop doing, and things to change. It’s important to get some consensus on the most important elements. In most cases, you’ll have way more potential action items than you can possibly implement immediately, so prioritization is key.

You can use interactive group activities to facilitate this part of the retro. A good way to get an idea of how the team is feeling is to ask each team member to vote on their top two or three priorities for things to start doing, stop doing, and continue doing. Hopefully, this results in a few clear winners. If not, it can initiate further discussion to get the team on the same page.

How many action items should you end up with?

As far as things to continue doing, you can include all of the items the team agrees on. The same generally goes for things to stop doing. The only potential pitfall here is if the things to stop doing need to be replaced with new systems. This adds an extra layer of complexity to the plan going forward, as new systems will need to be determined and implemented (which can be time-consuming).

As far as new things to try, this is where you’ll need to limit the number of action items. Trying to make too many changes at once can set the team up for failure. Instead, focus on no more than two or three new action items for the next phase of the project (or the next project). These should be thoroughly defined. Before completing the retrospective, you should also make sure to establish who’s responsible for implementing each change.

Retrospective activities

While you can definitely just ask the questions and facilitate a group discussion for positive and negative feedback in a retrospective, creating activities can help make the process more fun and interactive.

The most basic activities include using a whiteboard or sticky notes for collecting feedback simultaneously. Have everyone write down their remarks at the same time and then share. This can be done in person or via online tools.

Depending on the size of your team, you might consider breaking off into pairs to discuss each question and then sharing the answers as a larger group after. This can be particularly useful for large teams, since it keeps the number of answers being discussed smaller.

There are dozens of retrospective activities that take the same basic concepts of revealing positives and negatives in fun ways. Some examples are the Sailboat Retrospective—which uses the metaphor of an anchor holding the boat back and the sails driving it forward, the 4Ls—which stand for Liked, Learned, Lacked, and Longed For, and the Starfish exercise—the five points of the starfish represent Keep Doing, Less Of, More Of, Stop Doing, and Start Doing. Funretro.io has a huge database of ideas for interactive retro activities.

Conducting a solo retrospective

Just because you’re a solo designer instead of part of a team doesn’t mean you can’t benefit from a retrospective. It’s a good time to reflect on what’s been going well and where you still have room for improvement.

While a team retrospective is often based on activities that foster collaboration and communication, I recommend a more informal approach to solo retros.

You can still follow the main three phases of a team retrospective (leaving out the first step of setting the stage). But rather than doing formal activities, you can simply write and reflect on your experiences. Take out a notebook or open a note app and write down what went well and what didn’t. Consider all aspects of the project: the workflow, the communication with clients, the final design, etc.

Once you’ve made lists of the things that went well and the things that didn’t, you can create a plan for what changes to implement and what to continue doing.

Reflecting on your own work can be challenging for some designers. Try giving a bit of time between the completion of a project and the retrospective so that you can approach it with fresh eyes (a week is usually enough time). You may find it useful to jot down notes as you think of ideas throughout the process, ensuring that you won’t forget anything when you come to conduct your retrospective.

Try to look at your own work objectively, as if you were looking at a design someone else created. Remove your personal feelings from it and try to approach the entire process with a critical eye. As you do this more, it will get easier to do.

Retrospectives make you a better designer

Retrospectives are an important part of the UX design process. They also play a vital role in helping you become a better ux designer. Being able to honestly reflect on your work and workflow is the first step in improving both of those. Designers and design teams who adopt a growth mindset can find the retro process to be a vital step toward development.

Whether you conduct formal retrospectives as part of a design sprint or Scrum framework, or simply at the end of your projects, the insights you’ll gather can improve your team’s work together and elevate future projects.