Jan 30
Regular, well-run feedback and critique sessions are critical for helping to refine a product and make it great, and a lot of these sessions do not help accomplish those goals.
Doing critique and feedback sessions in a way that is constructive and empowering, without hurting feelings and trust takes practice and patience.
My team does a daily demo and critique. We have found that the more often you provide feedback, the more it feels like coaching and the less it feels like criticism. Critique should be empowering and in service of making better products.
Frequent feedback also prevents people from going too far off course. Once people get really far off course, the critique and feedback become a lot more painful.
People will also often feel like because they have worked so hard and spent so much time on something that they want to go forward with it. They have become incredibly invested in it. Feedback after someone has become invested in something is usually too late, leads to hurt feelings and often puts you in the position of remediation, instead of driving alignment around the highest quality product and design possible.
I consider feedback and critique critical to building thoughtful and useful products. I’ve put together a list of guidelines that everyone doing product design critique should understand (and these can be adapted for other areas of design).
I put together this list of core guidelines for critique and feedback that will help you run and participate in better feedback and critique sessions
Here are my core guidelines for anyone providing feedback and critique:
Trust comes first
People do not like receiving feedback from people they don’t trust. There are probably some good evolutionary reasons for this. Trust must be established before feedback and criticism can work well.
With a lack of trust, people become defensive fast. With a lack of trust, people also will get very personal, very fast.
Do not invite anyone to a feedback and critique session who the rest of the team doesn’t trust. Do not invite anyone to receive feedback and critique who doesn’t trust the people giving them feedback.
For an internal design team, you all need to trust each other. Building trust comes first, and if you don’t have that trust built up, I do not recommend attempting a feedback and critique session with an entire team.
Everyone should know the critique process and guidelines
Anyone invited to give or receive feedback and critique should understand the rules of engagement and how the process is going to go. Most of what you see in this list is not that hard to achieve, but it’s important to recognize that people can’t learn or follow good feedback and critique practices if no one ever lays out the rules of engagement.
Codify the rules of engagement for feedback and critique. Put them in writing. Make sure everyone knows them.
Be transparent.
There should be alignment around what is trying to be solved
If people disagree on what is trying to be solved, we can’t have meaningful critique of a design that is attempting to solve a specific problem. The person receiving critique should introduce the problem they are trying to solve and any requirements they may be working with, and then go over their design.
Disagreement over whether or not a design meaningfully addresses a problem is materially different than whether or not the right problem is being attempted to be solved. Both are meaningful pieces of feedback, but they need to be handled separately. Critiqued can go really off the rails if these two things get mixed.
If there is disagreement over whether or not the right problem is being solved, a discussion can be had about that, but it should be divorced from the design being presented.
Critique and feedback can be given at various parts of the user-centered design process. Sometimes critique and feedback is about some early ideation and prototyping that is trying to discover the correct problem to be solved, and in this case, the feedback vary well may be a discussion about whether or not the proper problem is being solved. Other times the critique and feedback is about something much higher fidelity, and the purpose of the session is to refine it and validate the solution is correct for the problem.
Feedback must be 360
The key to empowering critique is that everyone is giving feedback, and everyone is getting it. When you get to a situation where an exalted few give feedback but never receive it, people become a lot more guarded.
I run our daily demo and critique session on our UX & design team where team members demo what they have worked on since our last session (or since they last had something demoable). I present my work like anyone else and receive feedback from my team members.
Because I put myself up for critique from everyone else on the team, no matter how new or junior, those people in turn feel empowered to receive feedback from me and others.
Anyone above receiving feedback is also above giving it.
Feedback is best when it is cross functional
Product design requires several different skills to bring a product to fruition, whether it be physical, digital or a combination. Feedback and critique are best when it is a cross-functional team, because owning a high-quality user experience takes a lot of different skills and roles. My UX & design team (we are a SaaS company with some consumer websites) has product designers, UX developers, and user researchers.
The feedback sessions include all of these cross-functional roles, because all of these roles contribute to figuring out what we should build and why and then actually seeing through the design.
The UX developers ultimately are tasked with putting the designs into code, and their work is what users actually interact with. In their process of taking a wireframe or visual comp and making it real, they may discover better ways to do something or things that don’t hold up as well in code, for instance. They provide this feedback, and the product designers will give them feedback on ways to tweak anything that comes up like this.
We also empower the UX developers to provide feedback on the product designs, as well as empowering product designers to provide feedback on the product when it gets in code. And of course, we are always trying to align our designs and products to what we are learning from our user research.
Feedback should be frequent
This is where most feedback and critique go off the rails. A lot of Scrum followers have a demo every sprint, which is typically every two weeks or so. This is way too infrequent to give actionable feedback that doesn’t cause a lot of problems.
Imagine spending two weeks working on something, perhaps with several other people, and then getting a bunch of feedback on potentially major changes. Imagine if some of the decisions you are getting feedback on were made in day one or two of you working on this. It will probably go poorly, feelings will be hurt, and people will be defensive.
You may even become even less likely to deliberately seek out feedback.
Two weeks is a really long time to go before a course correction. It’s also a really long time to go in-between receiving affirmation that you are on the right path.
The other direction this goes is that people wait so long in-between getting feedback, that no one is willing to speak up. The demo happens every two weeks, people clap, no one says anything, and then you move onto the next demo.
How valuable is an internal demo without feedback?
The genesis of my team’s daily demo and critique is that if you provide feedback opportunities often enough, people will embrace receiving and giving feedback much more. It will also be a much more empowering process.
The goal is to talk about what can be improved AND what was done really well
The second part of this is so critical. I don’t know why so many people miss this. Any coach would tell you it’s really important to reinforce when someone is doing something well.
If someone delivers a design that is really thoughtful and meets user and business goals, go over the specific areas they did well and why. You want them to internalize what they are doing well and make sure they do it in the future.
Critique is good at finding areas for improvement. This is also critical. This helps a design and product become more thoughtful. It’s what takes a product from good to great.
But if you only focus on the areas of improvement, people are missing a very important signal on the things they should do more of in the future. If you don’t reinforce when people are doing something well, they may change what they are doing and do worse work in the future.
Feedback must be both actionable by the person you are giving it to, and actionable in the sense that it is related to the problem trying to be solved.
Feedback must be actionable
The point of receiving critique is to get actionable that you can use to improve what you are currently working on or to help you with future work.
Non-actionable feedback can be true. But if it’s not actionable, and remember this phrase, “it’s true, but irrelevant.”
I’ve had people provide feedback on typefaces, color, and other core elements of a design system and design language during a feedback session on product features like filtering or tables to display data. That feedback is way out of scope and prevented us from addressing the actual problem we were trying to solve for users.
If there is already an established design system in place, that would be an inappropriate time to talk about making a large-scale branding or design system change.
Feedback should be in context
The design may be displayed on a device or in a context that is not a typical use case. A lot of designs are demoed on large monitors that are high resolution in conference rooms, which can lead to the design being critiqued in an atypical context.
How many of your users are using your website, for instance, on a big 1080p monitor with the browser going full screen? This can lead to people complaining about excess white space or the design being too sparse. But if your user base is overwhelmingly on 13-inch laptops and you design for this, the critique should consider this context.
Another common issue is the problem of “desktop viewpoint,” where a product may be primarily used on mobile, but all of the people critiquing it stare at it on desktop on their work computers and mostly provide feedback for desktop use cases. This is a misalignment with how your users see the product.
You can’t fully recreate and test all user contexts, but you should understand the context your users will use your products in.
Feedback must never be personal
Critique is not about critiquing the person; it’s about critiquing their work.
Telling someone they need to work harder or that they are doing bad work is not constructive. It’s vague. It’s hurtful, and it’s not focused on providing meaningful feedback that can help make the product better.
You also want positive, affirmational feedback to be focused on the quality of the work and how it helps users, and not on the person. A key part of feedback when done in a setting with a team is that other people can learn from each other and the feedback that each other is given.
For trust purposes, it’s important to only allow people to provide feedback if they understand this point.
Feedback should always be from the users’ perspective
We build products to help users do things better. We build products to delight users. We build products to make users’ lives easier.
We don’t build products to keep product managers happy. We don’t build products because a salesperson thinks it’s a good idea. We don’t build products to keep ourselves happy.
Feedback should not be about, “I personally think X, and therefore you should make this change to your design.” Feedback should be focused around, “how will this feature you have designed help a user do X better?”
Yes, some feedback will be more pointed, such as, “this font size and contrast does not appear to be WCAG compliant,” but I have found that as much as possible, try to phrase things like question, and have the designer respond. “Is this font size and contrast WCAG compliant?”
Give critical feedback in the form of a question as much as possible
People try to respond to statements with rebuttals. The goal of feedback and critique is to get everyone involved in the process to think more expansively and to work to improve the designs and products. It should be a collaborative process that yields better results for everyone.
Giving your feedback as a question allows a person to think of it as truly an exploratory question — a question they may have never considered — and that may reframe their thinking. This will also give them the ability to give a thoughtful reply that changes the thinking of the question asker.
Also, when you think of feedback as about asking questions and less about making statements, those giving the critique will think more expansively and start asking questions that they themselves have no preconceived notion as to what the answer is.
Questions are empowering and expansive. Critique is about empowering the entire team to do better work together.
Encourage people to ask questions and be expansive in their thinking
This goes beyond trying to phrase critical feedback in the form of a question. Encourage people to ask questions about anything they don’t know, anything that may be come up.
Questions help people and teams expand their thinking. A question may be a simple clarification about the design or a feature of the product itself. Or it might be something along the lines of, “what if used some machine learning in this part of your design to surface recommendations of X for users?”
Feedback and critique sessions are a great time for people to push each other to keep thinking of ways to refine and improve products and designs. Some of these questions, like the example above, may be more long-term thinking, but it’s good to get the team thinking and discussing those bigger pictures ideas organically as they come up.
Everyone giving feedback should understand user problems and goals
Good product design is user centered. Everyone giving feedback should understand your users’ problems and the goals they may have. Everyone giving feedback should understand the problem that is being attempted to be solved with this design.
This means that everyone giving feedback should be apprised of your latest user research and should ideally have direct exposure to customers through user research or other methods (even if just as an observer). It also means that everyone giving feedback should understand what problems this particular design is trying to solve.
If good product design is ultimately about how something works, everyone giving feedback should have a sense of what they are even working towards.
Everyone giving feedback should understand business goals
If you are making a product to sell, the designs that are made and the reasons for them should ultimately serve business goals. If people providing feedback don’t know these goals, the feedback they give may actually hurt your business goals.
The difference between selling mass market ad-supported business-to-consumer products and enterprise software as a service products (SaaS) are vast. Anyone who doesn’t really understand how you make money and what your future business goals are, is not in good position to provide feedback.
Everyone should be engaged
Close laptops and put phones away.
People are more confident presenting when people are engaged, and what’s the point of a critique session is people are half paying attention? A critique session is not a meeting where you can just idly check email during. This is a time to sweat the details.
The exceptions to this rule are if you are getting ready to present or if you are taking notes. I try to take notes on pen and paper during these sessions or use a white board to help myself stay as engaged as possible.
Negative people aren’t invited (but assume positive intent)
Negativity and mean spiritedness will kill morale in most situations. Mix it with a critique session, and it can be downright toxic.
My job as a design leader is to shield my team members from negative and toxic influences. Some people never provide actionable and meaningful feedback. Others provide good feedback, but not in a constructive way. This can hurt morale and can destroy the confidence of talented designers and will lead to worse work in the future.
If someone is being too negative, they won’t be invited to future sessions, but, this is key, assume positive intent with people, and let everyone know this as one of your core compacts with each other ahead of time. Letting people know that you are assuming positive intent with everyone who is in the feedback session will help people build trust and provide constructive feedback.
If the issue is with a designer working with a product manager or some other stakeholder and that person has control over the product that the design is for, I will help demo the design with my designer to help deflect some of the negativity. I will also work privately with that stakeholder to try to get their feedback to be more constructive.
Anyone can learn to give meaningful critique
No one is born being good at giving feedback and critique. We have to learn it. Teach people how to do it properly, give people the right tools and techniques to do it well, and make sure that everyone knows everything they need to know about your users and business first, and you can have constructive feedback and critique with anyone in your org.