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.
Purpose
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.
Critique
The goal of design critique is to drive iteration. After critique, the design will continue to change.
A critique is effective when:
- All participants feel engaged in making the design better
- The critique-givers are confident they were heard and understood
- The critique-receivers are confident they can take action on what they received
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.
How to receive critique
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:
- What problem are we trying to solve?
- Who has this problem?
- What problems are we not trying to solve?
- How will we know we’ve solved the problem?
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.
How to give critique
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:
- It’s natural to have a gut reaction. Maybe it’s “I don’t get it,” maybe it’s “This is so cool!” Hold on to that reaction. Take time to ask yourself: “why am I having this reaction?”
- Make sure the recipient is ready for critique. Even feedback with the best intentions can be unhelpful if it’s given at the wrong time. If the designer hasn’t asked for critique, but you still want to share your thoughts, reach out and suggest that you discuss when it’s the right time.
- Understand the goals, audience, and constraints of the design. If you can’t find this information, ask questions.
To formulate your critique, answer the following questions:
- What is the objective of this design?
- What elements of this design are related to the objective?
- Are those elements effective in achieving the objective?
- Why or why not?
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.
Review
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.
What is an objection?
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:
- The proposal might put the business at risk
- The proposal could erode the trust of our patients
- This proposal might be harmful to anyone’s health or personal safety
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.
How to receive a review
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:
- Take a deep breath. It’s hard to receive directive feedback.
- Re-state the objection clearly. Say, “If I’m understand you correctly, your objection is that _____”
- If the stakeholder has not provided one, propose a solution. “If we do _____, will that resolve your objection?”
- If the stakeholder has provided a solution, but you can think of a more suitable solution, suggest it.
If you can’t quickly identify a solution, you may need to spend more time iterating on the design.
How to give a review
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:
- The intended audience
- The problem being solved
- The constraints and tradeoffs impacting the design
- The feedback that went into previous iterations
If the design doesn’t reach the level of “good enough”, or if it is not safe to try, raise an objection:
- Clearly state the way the design fails to meet our standards of quality or safety. Be candid.
- Have a solution in mind, but listen to alternative solutions with an open mind.
- Give the designer a roadmap to resolving your 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.