How to conduct a UX design retrospective

Profile picture of Cameron Chapman

{date}

{#hash1}

{#hash2}

Illustrations by {name}

Design retrospectives help you reflect on your workflow and results, enabling you to identify what can be improved in the future.

9 min read

Three people working together in office

Stay informed on all things design.

Thanks for submitting!

Shaping Design is created on Editor X, the advanced web design platform for professionals. Create your next project on Editor X. 

Get our latest stories delivered straight to your inbox →

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.



Team of designers in an office brainstorming with a whiteboard


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.



Three people working in office

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.