In-Person and Remote Design Critiques
We love feedback! We want to get as much of it as we can, as of often as possible, without it feeling like we’re spending more time trying to get feedback than doing the work itself.
At Gem, our approach to design critique involves both in-person and async processes, and over the past year we’ve learned (and re-learned) some best practices around each.
1. Weekly In-Person Design Crit
No surprise, we still find the best way to get detailed, high-quality feedback is to run a weekly critique ceremony—provided we’re doing so efficiently and effectively!
What is a Design Crit for?
The design critique (or “crit”) is a meeting where designers can get specific, ongoing feedback on their work from peers with knowledge of the problem space or experts in design.
Unlike a regularly recurring Design Review in which designs are shared with a large, cross-functional group, design crits are preserved for a smaller group. The small group means feedback is more focused on particular areas of a design at any stage of the process and everyone has a chance to provide input. This format helps the designer work through specific blockers and provides a space for high-context conversation.
Who should attend?
- Designers, of course!
- The product manager or product lead on the project
- Engineering leads on the project
- Additional project stakeholders as needed (optional)
All attendees should be active participants in providing feedback or, in other words, no “shadowing” the time. The more people not talking, the less others tend to speak up.
If your crit group is less than 8 people, that’s optimal. Any group larger may require the critique to be broken up by functional area (such as only designers) or the time will need to be spent focused on in-context feedback (like commenting all feedback directly in Figma or Sketch, more on this below).
Roles
On smaller teams like ours, some of these responsibilities will double-up (meaning a single person may take on two roles at the same time), but it’s very helpful to have a separation of moderator from presenter to keep things moving!
- Presenter: Prepares and presents designs
- Moderator: Keeps track of time, and encourages participants to follow the critique guidelines
- Notetaker: Keeps notes on any discussion not captured directly in Figma
- Participants: Actively engages and provides honest, thoughtful feedback
How to structures critiques
In-person sessions are 30 minutes or 1 hour depending on the scope of the work being shared.
We always start the meeting with a quick summary of the purpose of the time, the structure, and our shared guidelines, even if the same people attend each week. This helps us set the intention every session and stay aligned to it.
1. Designer presents (10–20 min )
The presenting designer provides an overview of their designs, including the following:
- I am showing [early/mid/late] work
- Around [the problem]
- Because [why it’s a problem]
- And am looking for feedback around [specific focus for feedback]
- A link to the working Figma file
2. Questions + capturing feedback (10–20 min)
Rather than immediately providing feedback, the critique group will have 10–20 minutes asking questions to better understand the mocks, problem space, project scope, etc.
During this time, participants will be heads-down in the Figma file, providing comments and questions directly on the mocks themselves. This gives people the opportunity to be thoughtful about specific reactions to the designs, provide in-context feedback, and not be overly biased by other people’s perspectives.
Additional tips:
- If the work presented is not in Figma, the designated note-taker should use the sign-up doc to capture discussion notes from the crit.
- If the amount of work being critiqued is extensive or covers multiple different areas, consider using a timer plugin to break up the feedback time and focus on each area separately.
3. Feedback (10–20 min)
After the initial questions and feedback time is up, now it’s time to conduct either a free-form discussion if questions have arisen, or have participants go around and share 1–2 pieces of feedback aloud (depending on time).
Participants should leave any additional comments they have directly in the crit notes or Figma files after the session has ended.
2. Guidelines for a positive critique
Participants:
- Lead with questions.
- Avoid providing solutions unless the designer requests it (they might).
- Identify what’s working as well as what’s not working — be specific.
Presenter:
- Actively listen to all feedback, avoid defending designs.
- Encourage feedback from diverse perspectives.
- Help participants understand the who, what, where, when, and why of the work they’re sharing.
Everyone:
- Be respectful!
- Have fun and work toward the best possible design.
3. Additional ways to critique
These days it’s not always possible to get time for a critique, or even if the team has time it’s impossible to get through all the work.
Async critiques are becoming a vital practice in the toolset of modern design teams. An async critique is an opportunity to conduct the same process outlined above for a critique, but enable anyone, at any time, to provide input and feedback.
Video walkthroughs
Recording yourself walking through a new feature, mock, prototype, or wireframe, is a great way to present work for feedback.
Setup
You don’t need fancy equipment to record a video, but it doesn’t hurt to have an optimized setup for recording yourself. If you want to invest in a great setup apart from your computer’s built-in webcam, try checking out Seth Godin’s setup and recommendations.
Really all you need is a built-in screen recorder and your design tool of choice! Don’t overthink it, just use what you have or are familiar with.
Recording
To record for async feedback, you can use built-in software in most any computer. Because we use Macs for our work, I’ll focus on that workflow for now. You don’t need to buy anything or learn to program, you have everything you need in front of you.
Start by finding the application on your computer called QuickTime Player. Once you’ve opened the app you can use the menu in the top-right of the screen to select File > New Screen Recording.
You’ll be presented with a way to record your entire screen, or just a small part of it. You can change the video recording options to include audio (or not). Then just press record to record yourself walking through the work just as you would if presenting in-person.
When you’re done, you can press a small circular icon with a square in it at the top-right of your computer’s menu bar. Review the video, save, then share!
If you want something that’s a little easier to use (but costs money), my team recommends Loom, which enables you to record videos on your computer really easily but also includes your face. The videos are hosted in the cloud too, so they’re easy to share and reference.
Sharing
Once you’ve recorded your video, share the link out wherever your team is (Slack, email, Confluence, wherever). You can re-enforce the feedback you’re looking for by sharing the who, what, where, when, and why of the work alongside the video link!
Additionally, consider including a link to the video asking for feedback in your working files (Figma, Google Docs, Asana, etc.)
Best practices
- Go slow. People will be able to pause the video, but walking through the setup slowly and clearly will dramatically help people know when is a good time to pause the video and focus or not.
- Include a link to the working Figma file (or other documentation) wherever you share the video recording.
- Set a timeframe within the video. Starting the video by saying something like: “I’m looking for feedback before next Friday, the 5th” is a great way to help people tune-in and provide feedback while it’s still timely enough to do so.
Sharing via Slack
The easiest way we’ve found to share work quickly is usually posting in Slack, though this can come with its own challenge of providing the right amount of context for the format. Some of the best practices we’ve learned are:
Post bite-sized design work
And be specific about the feedback you’re looking for. Targeted visuals will avoid you needing to to provide extensive context on the project for feedback to be valuable, and help others focus and give thoughtful feedback beyond “looks great!”
Tag the people who have the most context
If you have specific folks you want feedback from, great! If not, tagging people with context will get the conversation going and usually lead to broader engagement and feedback.
Thread the conversation so it’s easy to understand the evolution
This will help folks coming to the thread asynchronously to understand the conversations and iterations thus far. Replying with updated work directly in the thread can even be helpful days later if the context is still relevant, just make sure to also send to channel!
Cross-post for visibility
With separate channels for general design vs feature work, cross-posting can be a great way to explicitly request broader feedback on updates that you’re already sharing with the project group, or send people from the design channel to the feature space for more context. While not as focused as a formal critique, this kind of sharing gets us a more diverse perspective on our work and insights from across the company that we might not have heard otherwise.
Share the Figma file!
If you’re working in Figma, make this link easily accessible to those who want to go deeper. A common thread in each of our critique methods is to always point people to this source of truth. This helps us establish a culture of welcoming ad hoc feedback directly in these files without waiting for an explicit invite to provide input and critique.
