Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

Starting in 2023, the design team would like to introduce the concept of Peer reviews for designers. The concept of peer reviews is not new—our developers do it all the time. We just want to borrow it and appropriate it for design with the following goals in mind:

  • Ensure cohesive design across our platform

  • Provide design support so decisions don’t fall solely on one designer’s shoulders

  • Invite fresh perspectives into the design process for greater objectivity

  • Encourage collaboration and knowledge sharing

  • To enhance the overall quality of the design outcomes

How does it work?

When a design solution is close to complete (> 80% draft), we can request a review by another design team member. This is intended to be an asynchronous activity to give the reviewer time to look closely at the details and review on their own schedule.

To request a peer review:

  • Record a loom video walkthrough of your solution

  • Share for asynchronous feedback in the Design Team channel

  • Tag the peer you wish to review your work. Include the following in your message:

    • Summary of the project and solution including:

      • The primary problem you’re aiming to solve

      • The core use cases you’re accounting for

      • The requirements of the project

    • Any specifics you particularly want feedback on

    • Link to Loom walkthrough (if you recorded one)

    • Link to Figma file

    • Link to prototype (if you have one)

The reviewer

  • When a request is received by the reviewer, they should block time in their calendar to complete the review. Reviews should ideally be completed within a 48hr window.

  • The reviewer will do a detailed review of their peer’s work to identify:

    • UI inconsistencies

    • Potential ideas for improvements

    • Unaccounted edge cases or unhappy paths

    • Correct component usage

  • Be as specific as possible. For example, saying "I don't like the colors" is different than saying "These two colors are vibrating against each other and it's causing a distraction."

  • Give suggestions, not directives. And leave it up to the design to take the suggestions or not.

Who can I ask for a peer review?

The following designers are well-established in our design system and our product and can provide support in peer reviews:

  • Matt Birtch

  • Asaad Mahmood

  • Abhijit Singh

  • Anneliese Klein

  • Michael Gamble

Be careful not to ask the same peer every time to prevent bottlenecks with one of the peers.

What a peer review is not

This is not the right time to derail a solution. When a design solution gets this close to completion, we don’t introduce the peer review process to stall it. Peer reviews are all about softening edges, refining design work, and making sure we’re shipping the highest quality we can.

  • No labels