- Set context. Help the product team understand where the feedback is coming from e.g. the URL or page where you think that there’s a problem will get it solved quickly.
- Speak for yourself, don’t be dramatic/generalise. Be 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 everyone”. This will disarm the team.
- 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 of getting it wrong.
- It’s okay not to have context because users don’t. There are a million reasons why things end up a certain way. Users don’t care why. They only care about the experience they had. Don’t be apologetic about not having the context or feel the need to sugarcoat your feedback. Objectively relaying an experience shouldn’t offend anyone.
- 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 software developers and aren’t always experts, 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 our team’s job. 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.
This article is borrowed and adapted from Facebook’s product development handbook.
Comments
0 comments
Please sign in to leave a comment.