Do you ever get called upon to give product feedback? Here’s a guide to giving the correct feedback from the POV of a user for improving you product design

Do you ever get called upon to give design or product feedback?

A guide below 👇

Step 1: Recap for the feedback receiver your take on…
a) what problem this project is solving for users
b) who the primary users are
c) what success for the project is

Get aligned on this before giving any feedback, otherwise you might speak past each other.

Step 2: Put yourself in the shoes of someone who is the primary user, and go through the flow step-by-step.

Wear your user hat right now, not your ‘company employee’ hat, and don’t just focus on key screens. Experience the actual end-to-end experience.

The difference?

Company employee hat: “We need more people to click on X, and I’m skeptical this design will get us there.”

User hat: “When I get here, I’m trying to do Y, and this button about X isn’t compelling because…”

One is far more insightful than the other.

Step 3: Note any and all blockers or issues that might prevent a user from having their problem solved OR that may prevent this project from being successful.

Jot them down in “people language”–aka language that a person on the street would understand.

Not people language: “This page feels cluttered.”

People language: “There are so many options that I suspect our target user may feel overwhelmed or give up in trying to find X or Y.”

Step 4: Take a look at your list of issues and prioritize them based on impact to the overall experience.

Now you are ready to deliver the feedback.

Step 5: Summarize whether on the whole you felt that this project largely achieves, somewhat achieves, or is unlikely to achieve its goals.

This helps calibrate the rest of your feedback, as you may still have suggestions for improvement even if you think it largely works.

Step 6: Share the issues you’ve collected in priority order of importance, not order in the flow. Spend your precious face-time discussing the biggest blockers first.

You may not have time to go through all the issues; that’s fine. Send them via e-mail afterwards.

The discussion is meant to ensure that the feedback receiver understands why the issues you’ve brought up matter; don’t try to solve them.

Afterwards, I typically send my raw notes from step-by-step walkthrough (in flow order), with the top issues summary above that.

Step 7: Offer to look at future versions. Respect that the team may not take every single one of your suggestions–they have more context than you on the problem and your goal is to be helpful, not to be right, so lead with trust.