6 best practices for giving a product critique


There are two sides, or roles, in any critique:

Recipient: The individual(s) receiving the critique (i.e. the creator or presenter of whatever is being analyzed) who will take the perspectives and information raised during the critique, process it, and act upon it in some way.

Giver: The individual(s) giving the critique, who are being asked to think critically about the creation and provide their thoughts and perspectives.

Within both of these roles, there is the discrete aspect of intention: why are we asking for/receiving/giving feedback. Intent is the initiator of the conversation and is often what separates successful critiques and feedback discussions from problematic ones.

For the best discussions, the intent of each participant, regardless of whether they are receiving or giving critique, needs to be appropriate. If we aren’t careful, critique with the wrong, or inappropriate, intent on either side can lead to problems not only in our designs, but also in our ability to work with our teammates.

Receiving critique with the appropriate intent is about wanting to understand whether the decisions you’ve made are working toward your product’s (and its design’s) established objectives.

Giving critique with the appropriate intent is about wanting to help the creator understand the impacts of their choices with regard to their effectiveness toward reaching the design’s objectives.

Both acts are done with the intention of using the information and perspectives raised during the critique to iterate upon and strengthen the design. This is an important aspect of the discussion. Many of us have experienced meetings where we’re asked to give our thoughts on something like a design, or a process, or maybe even a project (ex: a postmortem), and over time, if these discussions repeatedly fail to produce action and changes, our desire to participate and provide our perspectives wanes.

Part of what makes for strong critiques is the desire to participate, to help. It isn’t the case that everything said in a critique will produce a discrete modification to the design, but overall, participants should feel that the discussion, which they actively contributed to, played a role in improving the design, not just changing it, but strengthening its ability to produce the desired objectives.

Prior to beginning a critique, whether you’re the giver or receiver, it’s best to make sure that you’re going in with the right intent.

Giving critique

As mentioned, giving critique with the right intent is about wanting to contribute to the improvement of the creation by helping the creator understand the relative success their design choices have in working toward objectives. When we start our feedback discussions from this mindset, we think critically not just about what we’re saying, but why we’re saying it, which is important to productive dialogues.

To better understand what giving a good critique looks like, let’s first look at some characteristics of bad critique. For more tips on handling and working with unhelpful feedback and unwanted critique, see Chapter 5: Critiquing with Difficult People and Challenging Situations.

Characteristics of Bad Critique


The wrong intentions for giving critique are often selfish. They’re focused on personal goals and desires for attention at the expense of the team or other individuals, specifically the creator of whatever is being discussed.

Selfish critique comes from the motivation of the giver to not only be heard and attract attention, but also to be recognized as smarter or superior, or further personal goals.

The most recognizable examples of this can be seen on social networks like Twitter or Facebook whenever there is a change to a popular app, device, etc. A new feature is added or something is changed, and people immediately begin slamming decisions, calling them ridiculous and stupid, and stating how things “should have been designed.”

But in most of these situations, the commenters have only a cursory understanding of what the designer or team was working toward and the constraints they were working within. How is this helpful?

When we do this (and Aaron and I are guilty of it, too, as are most people) are we really trying to help someone improve their design? Or are we more interested in showing others in our community or organization how smart we are on a certain topic?

This type of feedback happens on project teams as well. Maybe you’ve encountered it at work, are thinking of a colleague who’s done it to you, or maybe you’ve done it yourself.

Sometimes, this kind of feedback comes from having our own ideas of what we think the design should be but not having had a chance to share it with the team. So, we set about to use feedback as a way to diminish the design being presented and (in some cases) propose our own alternative. While Aaron and I are firm believers that a great idea can come from anywhere, and team members in any role should be given an opportunity to share their ideas, this path to doing so is detrimental to a critique.

As we’ll discuss more in Chapter 4, critique is not the place for exploring new ideas. Its purpose is to analyze the design as it has been created so far. Shifting a group from an analytical mindset to an explorative one is best done with deliberate facilitation.


Despite what we may think, and what some people may even say, people aren’t always looking to hear feedback on their work. Unless someone has specifically told you they’d like your feedback, it’s unwise to think your conversation is a great opportunity to share your analysis with them. If someone is telling people about their creation, it may just be to get the word out or simply that they’re excited about what they’re working on.

In order for the receiver to really listen, process, and make use of critique, they need to be in the proper mindset. Whether at a team member’s desk, in a meeting, or on social channels, when critique is uninvited, it can lead to defensiveness, communication breakdowns, and often paints the person giving it as a “know it all.”


For critique to be useful, the creator(s) need to understand not just the potential outcome or reaction to an element of their creation, but the why behind it. We often see feedback in the form of things like:

“I think the button is better than the link. Nobody is going to click on that.”

Or, even worse:

“This is terrible…”

This type of feedback typically comes from the reactive form of feedback we discussed in Chapter 1. It lacks the extended critical thinking that allows those working on the design to understand what they might need to change in their next iteration. In order for these critiques to become valuable, they need to be followed by an explanation as to why the giver is having that reaction or foresees a certain outcome. For example:

“Nobody is going to click on that because the current page design leads the eye down the left side of the screen, away from the call-to-action.”

Good critique is actionable. When the “why” behind the feedback is included, the comment can now be fully understood, and the creator can take action. That is to say, the creator has enough of an understanding of what is/isn’t working and why that they can explore alternatives or make other adjustments.

Note, though, that this is different from prescription or direction. It is not the case that critique should tell the creator how to act on something or specifically what changes they should make (i.e. the directive form of feedback). Good critique tries to avoid problem solving, as it can detract and distract from the analytical focus of the discussion. For more on this, check out Chapter 4.


Another common characteristic of bad critique is feedback that is justified by the giver from purely preferential thinking. We’ve all heard horror stories about this kind of feedback: designs are torn apart, not because a particular aspect isn’t working toward its objective, but rather it doesn’t match exactly what the feedback giver “likes.” For example: a website design gets canned because the color scheme reminds a stakeholder of a Christmas sweater his ex-wife had given him.

Though it might seem ridiculous, this kind of feedback is common, though maybe not always so extreme. It usually feels like it’s coming out of nowhere and has no relevance to the work we’re doing, but sometimes, it really just boils down to a personal preference.

This kind of feedback is not only unhelpful, as it does nothing to analyze a creation with regard to objectives, it can be distracting and counterproductive. This is especially the case when it comes from team members or stakeholders who are in a position of approval. In these situations, the team begins, consciously or subconsciously, to prioritize that individual’s tastes alongside or above project and user goals, even if they conflict.

Best practices for giving critique

Where critique with the wrong intent (done knowingly or not) is harmful, damaging teams, processes, and — most importantly — the product, useful, productive critique has the ability to strengthen relationships and collaboration, improve productivity, and lead to better designs. In order give the best critique possible, think about the following best practices when giving feedback.

Lead with questions. Get more information to base your feedback on and show an interest in their thinking.

Chances are, before being asked for your feedback, the creator(s) will give a brief explanation of what they’ve put together so far and how it would work. This gives you some context and understanding of the objectives they have and the elements of the design they’ve put in place to achieve them. But chances are, they haven’t explained everything. Actually, as we’ll talk about shortly, hopefully they haven’t explained everything.

This is your chance to open up the dialogue. By asking questions, you give yourself more information on which to base your analysis and give stronger, actionable feedback. And if done in a non-interrogative way, it shows the creator that you’re genuinely interested in not only their work, but their thinking behind it, which can make discussing it and listening to feedback a bit easier for them.

Examples of questions you might ask:

  • Can you tell me more about what your objectives were for [specific aspect or element of the creation]?
  • What other options did you consider for [aspect/element]?
  • Why did you choose this approach for [aspect/element]?
  • Were there any influencers or constraints that affected your choices?

Remember though, the dual purpose of asking these questions of the creator:

  1. to get you more information and …
  2. to get them more comfortable talking about their thought process and decisions.

To that extent, how you ask these questions can have a huge impact. Asking every question beginning with “Why…” can feel abrasive or like an attack. Use lighter, more inviting phrasing such as, “tell me more about…”

Use a filter. Hold on to your initial reactions, investigate them and discuss them in the proper context as appropriate.

You’re going to have reactions. As the work is being presented to you, there will be things that make you think “huh?” or “that’s cool” or “I don’t get it” or maybe something worse. Hold onto those reactions and remember that reactions don’t typically make for useful feedback. Ask yourself why you’re reacting in that way. Ask the presenters additional questions if necessary.

Once you understand your reaction and what caused it, think about whether it makes sense to discuss. Does it relate to the objectives of the product, the audience for it, or any particular best practices that should be followed? Or is it more about your personal preference or wishes for how you’d like to have seen it designed?

If your feedback is related to the product’s objectives or best practices, and not about your personal reaction or preferences, then it definitely has a place in the conversation. Sometimes though, you may find yourself with feedback that, while not a best practice or preference, is also not specific to a best practice or a stated objective. Maybe it’s something new that you think should be considered. What should you do in those situations?

In these cases, it may still be useful to bring your feedback into the conversation. These kinds of thoughts can be useful in determining additional objectives or constraints for the project that need to be exposed. It may be something you can discuss quickly and then continue on with the critique, or it may prove to be something sizeable that needs a separate, dedicated discussion so that the critique isn’t derailed.

Don’t assume. Find out the thinking or constraints behind choices.

“To assume makes an ass out of you and me.” Most of us have probably heard that line a few times in our lives. It’s one of my father’s favorites, and it’s stuck with me.

Assumptions can be one of the worst things to happen in a discussion that is meant to be productive. When we make assumptions, we begin to form our thoughts, questions, and statements around them, without ever knowing if they’re true or not. And before you know it, the participants of the discussion go on their way to do their work based on very different ideas and producing work that doesn’t align with each other or reality.

When you make assumptions in a critique about what an objective or constraint might have been, or maybe that there were no constraints and the designer could have done anything, you begin to offer feedback that can be less useful because it isn’t based on the real situation.

To get around this is simple. The quickest way to eliminate assumptions is to ask about them.

Yup. More questions. Put your assumption out there and ask if it’s accurate. If it is, continue on with your insights. If it isn’t, you may find that you need to adjust your thinking a little.

Don’t invite yourself. Get in touch and ask to talk about the design.

Recall in the previous section that we talked about untimely feedback as one of the types of unhelpful critique. If the recipient of the critique isn’t in a mindset where they want and are ready to listen to the feedback and use it, chances are it’ll be ignored or potentially cause a rift in your working relationship with them.

If you have thoughts about someone’s creation and they haven’t explicitly asked for your feedback or critique, get in touch with them first and let them know. Tell them that, when they’re at a point when your thoughts might be helpful to them, you’d be happy to share them. Give them the opportunity to get themselves ready to listen.

Talk about strengths. Critique isn’t just about what’s not working.

As a culture and society, we have a tendency to focus on negatives, the things that cause us problems, get in our way, and that we’d like to see changed. We often take the positive for granted. In our project meeting and design discussions, it’s often no different — we spend the vast majority of time talking about what isn’t working. But that can be harmful. Remember that critique is about honest analysis. It’s balanced, focusing on the design and it’s objectives, regardless of their success. It’s just as important to talk about what is working and why, as it is what isn’t working.

Often, when talking about the role of “positive feedback” in critique, we see discussions center on the importance of discussing strengths as a mechanism for making critical feedback easier for the receiver to take. There is a common structure often discussed called the “OREO” or “sandwich” method, in which you begin by offering a positive piece of feedback, followed by a negative one, followed by another positive one. It’s a fairly useful technique, which we’ll talk more about in Chapter 5, and there have been studies showing its effectiveness.

But there are other reasons for making sure that critiques include discussion on what aspects of the design are working toward objectives and why/how.

Part of the creative process involves the decomposition and abstraction of ideas and then recombining them in different ways or with ideas from somewhere else. It’s a common way in which we take a familiar concept where there is room for improvement or added value and innovate. When we talk about aspects of a product or design that are working, there is the potential for the creators to examine those areas and abstract concepts or elements from them that could be used to strengthen other areas of the design that might not be working as well.

Additionally, with the understanding that the creator(s) will iterate upon their design after a critique, how much would it suck if at the next critique, you noticed that an aspect of the design that seemed great previously had now been changed and wasn’t quite as effective, all because it hadn’t been talked about, so the team didn’t see a reason not to change it.

Think about perspective. From whose “angle” are you analyzing the design?

In the previous section, we talked about preferential critique, or feedback that’s based on personal preferences rather than being tied to objectives for what we’re creating. When we’re analyzing a product, it can be easy to forget that we most likely aren’t representative of the product’s target audience. Even if we are a potential user, we know far more about it than the average user.

As you analyze a design, it’s important for you to try to balance your expertise with the user’s perspective. It can be a difficult balance to strike, but by simply asking yourself “how am I looking at this” when you examine an aspect of the design and compare your perspective to what you think the user’s might be, you’ve got a good start. From there, you may find that one is clearly more appropriate than the other (i.e. your visceral hatred of the shade of green being used probably doesn’t matter), or perhaps it might be best to bring both up in the discussion. For example:

“From the user’s perspective, I think all of the steps in this flow make sense and are understandable and useable. But from an interaction design perspective, I think there may be some redundancy and opportunities to simplify…”

Cropped image on article and category pages by Dan G on Flickr, used under a Creative Commons license.

Arwind Yadav

Arwind Yadav

Arwind Yadav, is a IT professional with over twelve years of experience in conceptualizing, designing and developing software applications. He loves building web apps and has also well versed with all the aspects of e-commerce solutions, mobile applications and automation.

You may also like...