Structuring design artifacts for review

We design in the open, which means that anyone can view design artifacts at any stage of the design process. We want to make an environment where we can work transparently while still having space and the physiological safety to explore ideas, make mistakes, and to create some absolute crap along the way.

To help us do this, we explicitly indicate the state of our design work and what kind of feedback we’re looking for (or not looking for). Sometimes, this state applies to the entire artifact (like the Figma file as a whole), and other times, we’ll use labels and other indicators to point out specific sections in an artifact. Some examples include:

• Exploratory: We’re experimenting and exploring with ideas. We’re not thinking about making our design artifacts easy for others to consume and understand, and we’re generally not seeking feedback. This is a lot like working locally on a branch on your own machine, or like a draft PR.
• Feedback requested: We’re specifically requesting feedback from others. We will likely have organized a specific section of the artifact to make it easy for others to review and understand asynchronously, where we’ve indicated specifically what kind of feedback we’re seeking. This is a lot like asking for feedback on a PR.
• Source of truth: When we reach the end of a Discovery phase and agree as a project team what we’ll bring forward into Delivery, we’ll often create a source of truth in the design artifact to be used as a reference for implementation.

As a design team, it’s our responsibility to communicate expectations clearly and to make it easy for you to review design asynchronously.

As a teammate outside the design team, it’s your responsibility to understand when and how your feedback will be most valuable.

We have a set of guidelines for how to seek and give great feedback.