How we’re working to improve our design critiques at Treehouse.
When the designers at Treehouse started the mini-critique concept a few months back, I first asked each team to sit down and draft a set of working agreements. This was a simple google doc that listed 5–10 principles and behaviors they wanted to exhibit and hold one another accountable to. These would be the rules for the team and their culture.
It’s been just shy of 3 months since we kicked off. I wanted to sit down and get a feel for what impact the mini critiques were having on the teams. I also wanted to make sure the problems we set out to address were being corrected, and how well each team felt they were living up to their working agreements.
Giving and receiving quality feedback is the lifeblood of a design team. If the mini critique concept wasn’t helping us do that, we needed to know.
So how did we determine if the concept was helping? We used a retrospective. This provided an opportunity for the teams to reflect and reset for the upcoming months. It also helped me understand how each individual on the team felt about our mini-critiques.
Retrospectives Explained
For anyone who has never participated in a retrospective, they provide opportunities for a team of people to reflect on a specific project or time period and discuss what was successful, what could be improved, and how to incorporate it all for future work.
Retrospectives aren’t something you hear a lot about in the design world. They tend to be more prevalent in project management. Regardless, I have found them to be a valuable tool to use because they help teams identify strengths & weaknesses. They help provide the designers at Treehouse an opportunity to give feedback on our processes in order to grow and improve them. They are a great for designing and iterating on process.
What it takes for an Effective Retrospective
The nice thing about retrospectives is that they don’t differ much from a typical team meeting. You need an agenda, you need to keep track of time, and you need somewhere/something to record people’s feedback. There is one difference I do want to call out: participation.
Silence in a meeting isn’t always a bad thing. At times it can be normal — even expected — for someone to be quiet during an entire meeting. In a retrospective it’s the exact opposite. Silence is indicative of a problem.
Retrospectives are only effective when everyone who attends also participates. The primary goal is to hear from everyone who has been involved: stakeholders, managers, team members, everyone. The collective perspective must be put out in the open and discussed. Every single participant must feel like they have a voice and can be heard. If that isn’t the case, then you are going to miss out on important events and lessons that the team can learn from.
I use a technique called a check-in at the beginning of every retrospective. The idea is to get each participant to say something at the start of the meeting. I’ll ask people to answer a question like “in one word, describe what you need to get out of this retrospective.” It doesn’t have to be so pointed, sometimes I will try to keep it light hearted by asking “if there was a color that would describe how you feel about this project/sprint/concept, what would it be?” The team has fun and attempts to bend the constraints of the question a bit, but it works. Everyone answers. They all explain why they said what they did, and from the get-go a foundation of participation is laid.
Key Take-aways From our Mini-Critique Retrospectives
So, circling back. We did retrospectives with the mini-critique teams and focused them specifically on the the problems we are hoping to correct, and how well the teams were living up to their working agreements. What were the results? Well, here they are:
We still don’t know if removing the set weekly critique was helpful.
When we first started the mini critiques, the teams decided to do away with our set weekly design critiques in favor of trying on-demand, free-flow critique The teams all did say they felt like the feedback and critique they got was helpful, and came in a timely manner. It’s still not entirely clear if this change helped facilitate more or less participation. That’s something we will just have to continue to look at.
Everyone wants to share more.
I think this one is a big issue for remote teams. When you get in the zone of designing and your teammates aren’t physically next to you, it’s easy to forget to stop, share, and gather feedback. One of the ideas that came out of this was to set a reminder in slack using Geekbot. That way you have a daily reminder to share something. We may also experiment with setting some pre-determined checkpoints inside project timelines, but haven’t settled on anything yet.
Feelings of isolation still exist.
What was very clear for one of the teams is that they still feel isolated. We’re all remote, so this closely connected to that and something we will continually have to battle. Some of the ideas that to try and improve that were:
- Pair designing — where you do a screen share with a few other designers and work through a layout together
- Conducting cross-team brainstorms at the beginning of projects to help build a more diverse foundation
- Do rotating 1-on-1 meetings for the team to cycle through that are specifically focused on design feedback and critique.
It’s ok to let other designers be prescriptive.
This one surprised me a bit. I did my best to set a tone and expectation up front that feedback and critique needed to respect the decision making abilities of each designer. So if someone had feedback or critique they needed to keep it focused on the decisions being made and why it does or does not work. In other words, don’t prescribe to each other what you they should be done. This is something I struggle with, so I assumed the rest of the team did as well. But I was wrong: prescriptive feedback is something everyone is ok with. And actually, I’m encouraged by that. It means the designers at Treehouse want to have collaborative relationships with their peers and bounce ideas off one another. They want to take advantage of the chief benefit of being on a team: each other. I think that is a good indicator of a healthy team culture overall.
The big take away for me from the retrospectives: we’re making progress, but there is still room for improvement. We still have work to do before we have a truly great culture of feedback and critique within the design team. Retrospectives are helping everyone identify what works, what doesn’t, and what new ideas should be implemented.
Closing Thoughts & Resources
Retrospectives are still something I am learning about. They’ve proven difficult to do with an entirely remote team, but that doesn’t mean they are impossible. I read the book Agile Retrospectives and it helped me build a solid understanding of the structure, techniques, and best practices. If you know of any other resources, I would love to know about them.
Running a retrospective is like most things in life: the best way to learn how to do it effectively is practice. So schedule one with the team, see what works and what doesn’t, then adjust. After a few, you’ll start to figure it out.
