How to give better product feedback
At Facebook, we take pride in our open company culture. One way this manifests is being able to test out every product that’s in progress (also known as dogfooding) and give feedback to the team in an open forum.
I originally wrote this as an internal post to provide pointer to my coworkers on giving product feedback that’s better positioned to make an impact. Many of these suggestions apply to other companies too, you also can use them while giving feedback to products that you aren’t involved in developing, so I wanted to share this more widely.
When you give good feedback, you…
- help the product team be more empathetic for someone using their product and understand how they made someone feel
- demonstrate an overlooked use case or report something not working as intended
- share with the team your experience building something similar and how it ended up
The goal of giving product feedback should be to better serve our users by improving our product. Thus:
The best feedback is the one most likely to create empathy
and elicit product change.
When you give bad feedback, others feel like you’re trying to…
- show how smart you are
- elicit humor at the expense of demotivating a product team
- speak on behalf of the whole world
Bad feedback makes the product team defensive instead of more empathetic. When defensive, they are less likely to listen to you and change the product. And when you give feedback that’s unlikely to help better serve our users, well, that was not a good use of anyone’s time.
Tips for better feedback posts
1. Set context
Help the product team understand where the feedback is coming from. Before you start shelling out opinions, tell them who you are (Not your day job–your tenure and level is less relevant than what kind of a user you are walking into a product experience) and what you were trying to accomplish.
2. Speak for yourself, don’t be dramatic
As objectively as you can, describe what you expected and what actually happened.
Speak about your particular experience “I got confused” instead of generalizing “This is confusing” or “This will confuse users”. This will disarm the team and help them empathize with you.
The worst kind of generalizations speak on behalf of the whole wide world: “Nobody will like/use this”. Being dramatic is unlikely to make the product team start thinking about their work in a new context and change their ways.
If you’re relaying feedback from someone else, it’s extra important to also relay who they are. Sometimes you aren’t directly relaying, but you’re damn sure someone would have a bad time with this product. That’s still okay, just make sure you explain where they’re coming from. Remember that the whole point is creating empathy, a generalized “people will hate this” won’t help with that
3. Ask why we are doing this
If you’re having a lot of trouble understanding what the team is even trying to do and feel upset, ask “What value is this providing to the people we serve?” and just leave it there.
This might read a little passive aggressive but it’s better than making assumptions about why we’re doing something and accusing the team. Hopefully there is some end user value that you didn’t know about! If the team isn’t able to crisply articulate the value for users, only then it makes sense to get up in arms about why we shouldn’t do something.
4. It’s okay not to have context, because users don’t
There are a million reasons why things end up a certain way. Maybe the team couldn’t do the research to find out all personas and potential use cases. Maybe they didn’t have resources to build it properly. Maybe something turned out to be really complicated so the team tried and gave up. None of this really matters to our the people using the product, though.
Users don’t care why. They only care about the bad experience they had.
Don’t be apologetic about not having context or feel the need to sugarcoat your feedback. Objectively relaying an experience shouldn’t offend anyone. If the team responds back with excuses, re-emphasize the bad user experience you had and that we should fix it because we care about our users having good experiences.
5. It’s okay to have or not have suggestions
“Don’t give feedback unless you’re being constructive” is awful advice.
People that use our products aren’t designers or engineers, their feedback is no less valuable because they don’t have suggestions to fix something they had a bad time with.
This also applies to internal feedback. When you’re relaying your experience as an end user it’s not your job to find a solution. It’s the team’s job.
The opposite sometimes rings true, too. People don’t want to give suggestions to product teams because they don’t want to tell the team how to do their job. This is also bad. As long as you pair your suggestion with how it solves the particular problem you had, you shouldn’t refrain from giving it. The best suggestions don’t articulate a particular solution “Put a button here…” but its goal “Give me a way to…”, though examples always help deliver the point. Then it’s up to the team to come up with a solution that satisfies them and improves the experience you had.
Parting thoughts
Remember, the whole point of giving feedback is so that we can make our products better. The best feedback is the one most likely to create empathy and elicit a product change.
If you always ask yourself “How can I frame this feedback so it’s most likely to elicit change?” you’ll give more effective feedback, which will mobilize teams to improve products they’re working on and we will better serve our users.
—
Thanks to Hursh Agrawal for proofreading.
