How the Designers at Treehouse Handle Critique
At Treehouse, we appreciate the value feedback and critique brings to the quality of our work. Our design team has held weekly design critiques since it’s formation. But in the time our team grew from two designers to nine, we began to rely too much on the weekly critiques. As a result, the team started to suffer. Add in the fact that we are a completely remote team and you have a recipe for disaster.
Now I’m gonna level with you. As a designer, remote work can be brutal. I’ve done it in some form for my entire design career. The opportunity to form nasty habits that impact the quality of the work is constant.
This is specifically true when it comes to getting feedback and critique. When you aren’t physically surrounded by your team, it’s easy to forget they exist. Co-workers who swing by your desk to glance at whatever you happen to be working on aren’t around. There’s no opportunity for hallway high-fives or a team lunch. It’s easy to get deep in a flow and just forget to reach out for that second opinion.
Our weekly critiques were no longer serving the purpose they needed to. Here were some of the problems we had been experiencing on a regular basis:
- Critique wasn’t happening enough. Our once a week cadence didn’t always sync up with the life cycle of projects. People weren’t getting the feedback they needed, when they needed it.
- Video calls were ineffective. The size of the team no longer worked for a single video call. Once we got more than 4 or 5 people on the call, it became difficult to hold any kind of group discussion.
- The amount of work to keep tabs on was growing. None of us had the superhuman ability to keep track of the 7+ other projects the team could be working on at any given time.
- Not all team members had the relational connections to seek out a second opinion. Informal critique and feedback often happen on relational lines. For the newer members of the team, those didn’t exist yet.
The problems were clear, but what were the answers? As the Director of Design, one of my over-arching objectives is to foster an effective design culture at Treehouse. In this instance, we needed to just address the broken process in addition to making changes on the team and individual level.
From a process standpoint, the main objective was to implement something that would provide value to the designers and scale with the team.
The idea that seemed to have the most potential was to break the larger design team down into smaller groups. Mini Crits are what I called them (Designer Mini Critique Groups was the official name, but dang… that’s a mouthful). So, the design team split in half, making each Mini Crit four people total.
The smaller size immediately addressed a handful of the issues we’d been experiencing.
- Enabled more focused discussions.
- Limited the scope of projects any given person was expected to be able to give feedback on.
- Created clear relational lines for new members of the team.
With the the smaller sized teams in place, it was time to address the changes that need to happen on a team level. I wanted to enable each team to solve the problems they’d been experiencing across the board. As a part of the initial kick off meeting for each Mini Crit, the members took time to articulate working agreements. Each team agreed to a set of behaviors and qualities they wanted to exhibit and hold one another accountable for. Among them were be respectful, be honest, etc. You know… standard, decent-human stuff. A few unique highlights within each team were:
Share work as frequently as possible, not just at completion points.
This isn’t always a natural thing to do for designers. We have a hard time admitting we haven’t solved the problem yet. But, doing so allows you to get valuable perspective about your thinking and work before investing too much time in it.
Drop the formal weekly critique in favor of an informal, as-needed critique sessions.
Let’s get real. This one scares me a bit. I know from first hand experience that it’s too easy to just forget to ask. From a manager standpoint it leaves critique up to the needs of the team, which means I can’t completely control it. I have to trust them to take the concept seriously and do their jobs. Fortunately, the teams are small enough that it’s not hard to determine if someone has gone silent for too long. And it’s easy to do a quick check to see how things are going.
Strive to give feedback and critique that is both complete and wholistic.
“Nice work” by itself is a pretty unhelpful thing to say when giving someone critique. On the flip side of that, so is “This stinks.” Agreeing to give complete feedback — explaining why something is what it is — is incredibly helpful, not to mention a decent-human thing to do. Adding to that, making sure to give feedback within the entire context of Treehouse is a big deal. We have a lot of moving parts. It’s hard to keep track of everything. Making sure our feedback is holistic concerning Treehouse as a whole makes the team and the end product stronger.
Use the Sliding Scale of Cap.
Having a common framework/language to gauge how strong someone feels about a decision is important. Relying on “No, I’m really in to this” or “No, I’m really really into that” just doesn’t cut it. So we lean on this tool Cap shared a while back. It’s helpful, but it’s not a silver bullet.
Have a framework for settling disagreements.
The team is all pretty amiable. This is double edged sword. Sometimes I fear we don’t care enough. Either way, I asked the teams to determine how they would settle disagreements ahead of time. Sometimes Cap’s sliding scale breaks down (we’re both at 11!!!). Knowing how you want to settle those disagreements up-front prevents turmoil.
We’re into our second week with the new Mini Crit groups. So far, so good. Our plan going forward is to do a follow up in June to determine if the groups are still accomplishing the objectives we set out for them or if we need to further iterate.
Sometimes the systems and processes we institute in our organizations turn their backs on us. In extreme cases they end up accomplishing the exact opposite of what they were created to do. It’s not always obvious to treat them the same way we would a feature that is broken or underperforms. Systems and processes must be revisited and iterated on. We must be willing to apply the same principles used in our design work to solve the problems in our structures, systems, and processes.
