How To Give Helpful Product Design Feedback

It may seem hard to believe, but only a couple of decades ago, it was nearly impossible to provide feedback on new or redesigned products. Take for example, Crystal Pepsi. One day in 1992, while you were looking for your favorite dark brown soda on the shelves, here was this new clear thing! You tried it, shrugged it off, and likely never bought it again. Because the process of providing feedback to companies was so difficult back then, you simply voted with your feet.

If you were intensely motivated, you’d pick up a phone book, call Pepsi headquarters long-distance, hope to get routed to anyone close to the Crystal Pepsi “user experience” division, and then come up with some sort of feedback smart enough to justify the amount of effort you just exerted. Or maybe you’d handwrite a letter and mail it off to a possibly unmonitored mailbox.

Barely anybody did this, and the end result was that a lot of products, including Crystal Pepsi, failed without their creators knowing quickly enough why people were rejecting them.

But now we have Twitter! And evvvvvverybody has feedback.

On evvvvvverything.

Always.

The downside is, when feedback is so easy to provide, often less consideration goes into it, making it less valuable to designers, PMs, and engineers as they try to address problems.

“Oh you mean I only have this little text field for the longer novel I could easily write about these terrible changes of yours? Ok then… I’ll just type a provocative sentence and be on my way!”

Feedback is a gift, and if you are lucky enough to work on a product that people care enough to give feedback on, you should take it very seriously. However, as professionals in product design and development, giving good feedback is also a responsibility of ours. We should be the best in the world at it! Unfortunately, we aren’t always.

Instead of concentrating on providing feedback that will help our colleagues improve their work, we often spend our time thinking of remarks that will make us look or feel smarter.

“What can I pack into 140 characters that is so insightful or funny or provocative that a bunch of people will fave and retweet it?”

I know I’ve certainly done this before. While it’s a free country (for now), and people can say whatever they want, as professionals who work in product development, we owe our colleagues more than that. We owe them civility by default and an honest effort at being helpful. In order to be helpful, we need to think a little deeper and provide feedback that reflects our understanding of how products get built.

To help us all get better at this, I came up with a framework to better guide our critiques of the changes, redesigns, and launches of our colleagues. Each level in this framework reflects a deeper level of empathy and understanding which ostensibly leads to more helpful feedback.

Level -1: Troll

Intentionally demean others or their work.

Example: “This is awful and whoever prioritized or produced this work is an idiot.”

Appropriate Usage: None. There is no good reason to ever do this. This type of statement does nothing to solve any problems and insults human beings you’ve never met, who are working under circumstances you are blind to. Type out a Tweet if you must, delete it without publishing, and then move on.

Prerequisites: Being naive, inconsiderate, or both

Level 0: React

Put into words the way something makes you feel.

Example: “Something about the navigation just feels wrong.”

Appropriate Usage: This one is tricky because for laypeople, it’s ok, but for professionals, we need to do better. In other words, I don’t begrudge an average user for not being able to express why they don’t like something about the navigation. That’s their feeling, and if there is the bandwidth for it, designers and researchers can further explore that in a conversation. As professionals though, we should keep statements like this to ourselves until we can more constructively communicate why we feel the way we do.

Prerequisites: None

Level 1: Identify

Point out an actual issue that you have encountered or worry others may encounter.

Example: “The navigation is more cumbersome because the page I use most — my Profile — is now two taps away.”

Appropriate Usage: This is the baseline level of feedback we should expect from ourselves as professionals. It doesn’t really delve into solutions or inquire about what tradeoffs might be involved, but it crisply communicates a problem so that designers on the other side can consider it and respond/remedy appropriately. It can also be more subjective things like a certain shade of green not going well with a certain shade of purple, but it needs to be articulated as specifically as possible.

Prerequisites: None

Level 2: Understand

See something that looks sub-optimal and begin an inquiry to figure out why.

Example: “The Profile page is much harder for me to get to right now. What advantages are achieved with this tradeoff?”

Appropriate Usage: Now we’re getting somewhere. Product design is a series of tradeoffs. Simplicity vs extensibility. Speed vs power. Whimsy vs seriousness. When designers move something around, it is usually with an objective in mind. That objective could even be to intentionally get you to do something less frequently. Designers, however, often misfire and don’t fully appreciate what they are giving up for what they are gaining. Worse yet, sometimes they may be gaining nothing at all. It is more than fair to ask these questions. It is helpful! Often in the course of giving Level 2 feedback like this, you may in fact cause the designer to think of this tradeoff for the first time, since they may not have even realized the magnitude of the downside.

Prerequisites: Observations from Level 1

Level 3: Propose

Identify a problem, understand its cause, and propose a possible remedy.

Example: “Ah. I understand it makes sense for my Profile to live with its related navigation items and they won’t all fit down below. Have you considered making the nav customizable so people can swap in their Profile if they want?”

Appropriate Usage: Level 3 feedback must be given in the right way, because if not phrased properly, it can come off more like Level -1. For instance, “Why the hell wouldn’t you just make this all customizable you idiots?!?!” is a lot different than the example text. That sort of phrasing is not only inconsiderate, but it also assumes the issue is simple… and they rarely are. The trick with Level 3 and Level 2 feedback is an exchange of empathy. You want designers to have empathy for you and the problems you are encountering with their product, and you also want to have empathy for the designers and the problems they are trying to navigate through, whether it be deadlines, business goals, conflicts between stakeholders, resource constraints, or any number of other things that we always try and keep behind the curtain. To be clear, average users do not and should not care about these things… all they know is the experience that has been put in front of them. However, as professionals we know better than to discount the complexity of what goes into our work. A good rule of thumb is: if a problem seems simple to you, you probably don’t fully understand it. You certainly might, but you probably don’t, and therefore, you should treat your critiques as investigations or explorations and not conclusions.

Prerequisites: Observations from Level 1 and findings from Level 2

You may notice a pattern here in that as you go up each level, more thinking is required. You may also notice that a lot of the most valuable feedback you can give may not actually fit in a single Tweet. It may require you to first reach out and get more information before you form an opinion. It may even inspire you to write a short article expanding your critiquelets into well-formed, helpful observations, which not only end up making it into the product, but may end up getting you a great job somewhere.

If all of this sounds like a lot of effort, think of the hundreds of hours of someone else’s work we so brazenly and publicly try to cook down to a single sentence. While we can’t avoid the barrage of hot takes from people who have never even heard of product design, we can absolutely commit ourselves to being as helpful as possible when we critique the work of our colleagues.

Thanks to Marc Hemeon, Mike Rundle, and Kory Westerhold for reading and improving drafts of this.

(This post also available on Medium.)