Goals

As in any good design process, we first had to align on the goals of critique. Only then could we understand and measure if our meetings were actually achieving what we needed. We decided on the following:

1. Unblocking problems & generating ideas: Many times designers feel stuck on a problem after staring at it for too long, and find it helpful to leverage the broader team to move forward confidently. Other times you’re just getting started, and want to collect any ideas that your team may have already thought of.
2. Elevating quality: Everything from visual design, to interaction details, or overall product direction.
3. Encouraging consistency: We wanted to make sure we were leveraging existing patterns where possible, or flagging when there’s a need for a new one.
4. Sharing context: Design teams are small enough to be in the unique position of having good context for what’s going on in the company. This allows people to identify overlaps and connections between projects that people in other roles might not have as much access to.

Noticeably missing from this is: “Making major product decisions” or “Determining product roadmaps.” Design critiques are not the forum for that; teams should have separate roadmapping processes to determine direction. Critiques need to remain a safe space for exploration and feedback, independent from roadmap decision making and free from stress.

Ultimately, critiques exist to help the designer/presenter — the person looking for support. In that way, it’s really up to them to utilize the best approach to accomplish that. The rest of the design team simply needs to commit to being present and ready to help.

6 Critique methods

With those goals in mind, we put together six different critique methods, each with their own strengths and purposes. They are designed to take place either in a 1-hour meeting (usually 2 topics, 20-30 minutes each) or in smaller ad hoc meetings, depending on the method. With the exception of the “Paper Print-Out,” any of these should work great for remote teams as well.

1. Standard

Standard format. Present context, receive feedback.

Best when: You want people to understand the context behind the project, and to walk them through your thinking. You’re ok with some discussion, and ideally, have specific feedback you’re looking for.

Step 0: Set-upBefore or as people are walking in, set up sticky notes and pens at each chair to encourage people to write down ideas throughout the meeting.

**Step 1: Sharing context & internalizing feedback (~10-15m)**Start the meeting by explaining the context of the project (if people aren’t already familiar with it). Why is it important? What are the goals? The project goals are the foundation of the project, and if people miss that part, their feedback will be misdirected. Decide if you want people to interrupt with questions, or wait until you’re done sharing, and let them know which you prefer. Include a slide dedicated to “Here’s the feedback I am looking for,” and conversely, “Here’s what I’m NOT looking for” to keep the discussion focused. Remind them to write down their thoughts as you’re going through the content.

Rather than present on a big screen, we often send everyone a Figma link and have them jump into Observation Mode. We find it much easier to see details this way, it works great for remote participants, is more reliable connectivity-wise, and better for high frame-rates than most screen-sharing software. You run the small risk of people wandering in the file rather than observing, but we’ve found that can also sometimes be a good thing if someone missed something but didn’t want to stop the full group for it.

**Step 2: Clarifying questions (~2-5m)**After you finish presenting, take a few minutes to allow anyone to jump in with clarifying questions. This is important because if one person is confused, it is likely others are as well. You want questions clarified before folks jump in with feedback to ensure everyone is on the same page.