Hi again. It’s me, Matt.
Every year or so, I sit down to wrestle with the topic of design feedback. It’s the metronome that designers live by. Good feedback, delivered well, is like a steady breeze at your back. Bad feedback, delivered poorly, makes design feel like running head-first into a wind tunnel.
I’ve written a few essays on feedback. Five years ago, an attempt at a standard vocabulary for feedback. Three years ago, thoughts about facilitating feedback.
Today, a practical approach. The essay below is a snapshot of a working document I shared with my team at Simple Health. It’s meant to give us all a shared point of view, a common language, and clear expectations.
If you’d like a shorter, more entertaining — but equally if not more informative! — guide to feedback, check out Dan Saffer’s essay, “Everything I’ve Ever Learned About Giving Design Critiques I Learned from Tim Gunn.”
Now, on to the guide.
Design feedback is one of the challenges I return to over and over again. It never seems to get easier, no matter how many times I practice or how many different tactics and frameworks I try.
Recently, I did my first rounds of feedback with a new team. Once again, I was nervous. To try and ease the uncertainty, I wrote a guide to feedback based on my past experience, and shared it with the team. While the feedback session still exhibited some classic speed bumps — prescriptive feedback, uneven participation, ‘can we see a few options,’ — I believe the shared context set good baselines for us to improve on in the future.
So here’s the guide. It’s a work in progress, and I already have a few small tweaks to make based on our first feedback session. But I thought it would be useful to share.
The goal of this document is to establish consistent guidelines for giving and receiving feedback on design, as well as reviewing and approving design as a group.
Please read these guides before attending your first critique or review.
Much of this guide is adapted from Discussing Design by Adam Connor and Aaron Irizarry.
The goal of design critique is to drive iteration. After critique, the design will continue to change.
A critique is effective when:
A critique is ineffective when: - Some participants don’t have a chance to contribute, and others feel like they have nothing to contribute - The critique-givers aren’t sure they got their point across - The critique-receivers aren’t sure they understand how to proceed
Critiques can be large or small, and they can include everyone from stakeholders and decision-makers to the generally curious.
The key to getting effective critique is creating a shared point of view before asking for input. Establish this baseline by answering the following questions:
When presenting design, provide context to critique-givers on your decision-making process. Call attention to elements of your design that solve problems, and point out constraints. Remind participants of our design principles and industry best practices. Solicit and answer questions.
Most importantly, listen actively and read with an open mind. Receive critique without judgement, practice empathy, and express gratitude.
Giving critique is a skill; it begins with the right intentions and takes practice to get right. Great critique helps improve design. Poor critique leads to frustration and confusion.
When looking at a design, start with intentions:
To formulate your critique, answer the following questions:
When providing critique, try to share what you think is working with as much enthusiasm as you describe what isn’t working. Avoid the compliment sandwich; be clear, candid, and kind.
The goal of design review is to commit to a final design. If the team commits, no more work is needed. If there are objections, everyone will have clear steps to resolve them.
A review is effective when: - The team commits - Designers have the full backing of the stakeholders to proceed - Stakeholders have the time and space to voice any objections - If there are objections, - Designers know exactly how to resolve the objections - Stakeholders know when and how their objections will be resolved
A review is ineffective when: - The team does not commit - Designers don’t feel trusted by their stakeholders -Stakeholders don’t feel like their objections were taken into account - If there are objections, - Designers don’t know how to resolve the objections - Stakeholders don’t know when or if their objections will be resolved
Reviews should be small. They should only involve decision-makers or key stakeholders. Reviews are about consent, not consensus.
Design reviews are similar to code reviews: code reviews find bugs, maintain consistency, and raise potential integration issues. Code reviews are an important step in maintaining a fast-moving and collaborative code base. In the same way, design reviews help designers remove blind spots and maintain a consistent quantity and quality of output.
An objection is a very specific, very powerful form of feedback. Objections come from asking the question: Is this safe to try? An objection should be raised if:
This gets at the heart of what makes design reviews so hard: as a stakeholder, you are accountable for the outcomes of the design, even though you are not the person doing the design.
This tension is why we don’t ask “is this the best it could possibly be?” It’s a question breeds skepticism; it comes from a position of doubt. The answer to this question is always “no, it could always be better.” And nobody knows that better than the designer.
Finding “good enough” — a point that is within the safety margins of the project — allows the team to deliver quickly. Fast delivery gives the team time to gather data and solicit customer feedback. This research helps us raise our standards. “Good enough” is a virtuous cycle.
First, establish a shared understanding with your stakeholders. By the time a review happens, the design has probably gone through many iterations. Recap the history of the design. Explain why decisions were made. Re-state the problem and intended outcomes. Clearly define the audience. Make it obvious exactly what you’re seeking commitment on.
If a stakeholder raises an objection:
If you can’t quickly identify a solution, you may need to spend more time iterating on the design.
As in critique, it’s important to understand the context of a design when giving a review. If you don’t have the necessary information to assess the proposed design, ask lots of questions. Make sure to understand:
If the design doesn’t reach the level of “good enough”, or if it is not safe to try, raise an objection:
Objections should be raised with care. Discussing objections requires vulnerability, but addressing them directly is the fastest path to closing feedback loops and committing as a team.
This document comes down to a question: how can we building a positive, efficient culture of design feedback?
If you’re doing this in your own work, reach out; let me know what’s worked, and what hasn’t.