Giving constructive criticism on a product is hard; providing the unconstructive kind is quite easy. Despite being one of the most important processes in product development, giving feedback is arguably the least enjoyable for a team. Fortunately, like most things in life you can get better.

If you want to share your opinions but are tired of colleagues running for cover when you approach their desk, ask yourself these four questions. They'll help you provide actionable ideas without annoying your team. Who knows, maybe they'll even start reading your emails that start with "thoughts on latest prototype."

What Should I Provide Feedback On?

When using a prototype you'll tend to zero in on the things that look funny or behave a bit weird; I have to admit it's pretty satisfying to point out things you know are wrong. Despite how annoying that off-center text label may be, at this stage those details you noticed are immaterial. It’s a prototype and bugs are expected - in fact if there are no bugs then you spent way too much time on it and are probably already behind schedule.

The type of of feedback you give should be a function of time. This is modeled by the following unscientific curve, where the level of detail ranges from low res ("I don't understand this feature, should it exist?") to very high res ("that corner radius can shrink by 2dp, it looks like a marshmallow").

A good rule of thumb is that broad, qualitative feedback is most valuable earlier in the development cycle and when you get closer to the deadline, small details and bugs become the primary focus. If you hacked together a low-resolution prototype and showed it to someone, the last thing you want to hear is that the line height could be a pixel or two larger. 

Spending time making local optimizations this early is like telling NASA where to paint the little American flag on the Saturn V before they’ve figured out how to get to the Moon. You should focus more on big picture questions like 'does this product even fulfill a need?' or 'is the information architecture clear?' Once you get closer to launch you can start focusing more on polish and the little details that make a lasting impact on your users.

Should I Interrupt?

So now that you have a relevant issue to bring up, the easiest way to notify someone about it is to walk up and tell her. However every time you interrupt someone who's working, productivity takes a nosedive (perfectly illustrated here). It's unfair to disrupt someone because you're too lazy to file a bug, so the next time you wonder  “should I interrupt right now,” first check:

1. Is this issue easy to reproduce?
2. Am I able to continue using the app if the issue remains unresolved?

If the answer to any of those questions is 'no,' feel free to walk over to her desk and work out the problem in person. Transient bugs are hard to replicate and catching one in the wild is like encountering a rare Pokemon - that may be your one chance. Once you see the issue, any information regarding how it came about and what state it’s in is both invaluable and fleeting (see the next section).

If your problem fulfills both criteria then you can shoot an email, use your favorite trendy messaging service (well probably not Snapchat), or file a bug. Be sure to include the steps you took to reproduce the issue!

What Information Should I Include?

“Hey {your_name}, X is broken” is the single most useless statement you can make about a product. There are a million different ways something could be ‘broken’ and without any context it’s impossible to figure out what you really mean. If you’re describing the way a feature misbehaves, explaining what you were doing or trying to do can shed some light on what the actual problem is. Simply answering the what, where, when, and why upfront will save you a lot of time.

Screenshots and pictures are also extremely helpful; if you’re testing a mobile app then any details about the device you’re using are important as well. That can include info like the type of phone/tablet, OS version, if you were on WiFi / 4G / in a tunnel,  etc. There is no such thing as over-communicating when describing how something went wrong.

How Should I Say It?

Phrasing matters; we're human after all and have squishy brains that interpret words and sentences differently. It's best to phrase your feedback in the manner most likely to be well received and understood rather than ignored. To be clear that doesn't mean you should avoid negative comments, but your feedback should always be about the product, not the competence of the person who worked on it. 

Even a simple habit of preceding criticism with "I wish" (an old trick) helps underscore the point that your feedback is never personal. "I wish this layout was more clearly organized" sounds much better than "this layout is a mess" and it's easier to work with someone you haven't pissed off. Of course, if you know your team really well then you should do what you know works, but remember to always have some empathy! It only takes a few extra seconds.


It might not be the most thrilling task, but quality feedback can transform your team's treasured Rapid Prototyping Culture from Brownian motion into clear, guided progress. Getting used to providing effective feedback makes everyone's lives a little bit easier and hopefully your users a lot happier.