Then something interesting happened. During the meeting, people started proposing one idea after another. The energy was light and fun, yet productive. This was ironically the exact feeling we wanted to replicate during critiques themselves!

What was it about this context that allowed people to loosen up and get creative? Perhaps the stakes were lower? Or no one person felt they personally were getting critiqued? Whatever it was, we were clearly working well together, and it felt great. By identifying the positive flow of the room as it was working, and acknowledging it, we knew our target.

Recognizing we wouldn’t solve everything in one discussion and that this would be an ongoing process, we created a “#design-crit-crit” channel in Slack to keep iterating together. Especially as our team grows, and as the types of problems we work on change, we wanted to make sure our process is always evolving with the company.

Ongoing suggestions in the #design-crit-crit channel

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:

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. Elevating quality: Everything from visual design, to interaction details, or overall product direction. 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. 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.

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.

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-up

Before 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.

Step 3: Receiving feedback (10m+)

We have two very different approaches to receiving feedback from the room. We’ve branded them to make them easier for the facilitator/presenter to request which form they prefer to receive feedback in:

Round-The-Room (RTR 🎡) — Go one at a time around the room, and give everyone a chance to voice their feedback. Try to keep it to two minutes per person. No “interruptions” from others — if they have a pressing thought, encourage them to write it down for their turn. It’s important to go one at a time and give space for the person speaking to help folks who may not normally feel comfortable speaking up in groups. Having a structured format to receive feedback like this enables us to be more inclusive of different people and preferences. Allow people to “pass” if they have nothing to add, or if they’d like to think more and provide feedback later.

Popcorn (🍿) — Freeform discussion. It’s called Popcorn because comments pop up from all over the place unpredictably. This is more improvisational and helpful for flowing conversation where people can jump in with “Yes, and...” We often use Popcorn if we’re short on time and preface it with, “Any one have any critical things you feel the need to share?” Then we’ll document any other comments later. However, please note that this method can be dangerous for inclusion as it can reward the “loudest voice.” To combat this, I’d encourage the group to call on people who haven’t spoken (if they’re comfortable with that), or moderate the conversation a bit if it’s getting lopsided.

As you’re receiving feedback, try not to get defensive and justify everything. It’s best to model good behavior by simply thanking people for their feedback. You don’t need to respond immediately to everyone’s points. It’s ok to take time to consider what they’re after and get back to them later.

Step 4: Thanks & follow-ups (1m)

Don’t forget to thank everyone, and let people know how best to send you feedback if they think of anything else. Should they send it via Slack? In a notes document somewhere? In the Figma file? Are you free to meet with them individually? If so, when? You could also put the work on them to find time with you, which can filter out people who felt strongly enough to do that. More often I prefer to make it as easy for people to contribute as their ideas are usually quite helpful.

Brainstorms, Crazy 8's, Mood boarding, Sketching, etc.

Best when: You’re very early on in a project. Maybe you’re looking to soak in as much as you can from other people about what they may have already thought about or explored in the past. Maybe you just want a kick-start to be as divergent and exploratory as possible before starting to narrow in. Your design team brings together so many different perspectives and skills that involving them early can often inspire entirely new concepts, and help avoid tunnel-vision.

How: There are lots of methods out there for brainstorming. If you’re using paper, personally I love the Crazy 8’s method. Our favorite way of doing these, however, is inside of Figma itself. In particular, one recent fun example was when one of our design interns, Andrew Shen, got a bunch of us in a room to research his summer project, “Comments in Figma.”

All Andrew had to do was drop us a Figma file with a few prompting questions for us to jam on. Things like, “What are the biggest problems with comments today?” “What commenting experiences do we like?” “Any ideas on how they should behave?” “Should they be more like email or like Slack?”

Then we were off to the races — we went heads down for 30 minutes and started dropping in references, snippets of texts, and anything else we could to get our ideas across. This quickly became much deeper than just a survey or a poll because you could see others’ ideas in real-time, and start to riff off of them together. After going heads down, we went around the room and discussed each other’s ideas, adding any clarification where needed. In just a single hour, Andrew had leveraged the collective brainpower of six people, and had tons of material to work from when starting to sketch out some ideas.

Andrew’s Figma file for us didn’t require much prep or even facilitation — just a few empty frames with questions in them and we were off to the races.

Work in small groups of 2-3.

Note: the person second from the far left is a customer, not a Figma employee

Best when: The problem may require more context and deep work. It’s hard to get a big room thinking about everything all at once, so organizing participants into small groups is much more productive

Perhaps our most popular alternative method so far, pair designing has become a staple in our process at Figma. So much so that for a little while, once a week we dedicated one of the critiques to strictly using this method. We’d start each meeting by dividing people up into groups of no more than three people to tackle problems.

We’ve since moved away from requiring this once a week because it didn’t feel right to force people to use a method if they weren’t ready for it. Instead, we’ve started encouraging people to plan these meetings ad hoc. Now, people simply shout out in the design channel on Slack, “Hey, anyone free to pair?” — then they schedule a separate time together.

Another way to encourage frequent pair designing is by assigning a “co-pilot” to any lead designer working a project. At a start up like Figma, we’re a small team so there aren’t enough designers to have multiple people on the same problem full-time. We found that by assigning a partner even just part-time, it can make a big difference in feeling less alone while solving a problem. It hasn’t been perfect or consistent; for many projects we forget to assign a co-pilot or people simply get too busy. But as we grow, we hope to formalize this further.

It’s worth noting that pair designing is not a new concept. Engineers have been pair programming for years to help debug problems and catch mistakes. Going back even further, as far back as 10-220 CE, Rabbis used to urge students to acquire study partners under a process called Havruta; an approach to Talmudic study where small groups analyze and debate text together: