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:
Setting the stage
Reviewing what went well
Assessing what needs to be improved
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.
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.