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.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Okay, serious question: what net results in greater efficiency for everyone when A asks B for a favor via e-mail.
1) B declines by not responding. 2) B declines through e-mail response with why they are declining. 3) B declines but it's just a simple "no" with no explanation.
I used to think 2 (because I prefer to get a definitive response as A and it's a nice human touch to know why from B). 2 and 3 also saves A from not having to reping if it's actually a favor A cares about.
On the flip side, there are situations where A asks for a favor but wouldn't reping, and getting 2 or 3 can feel worse than not hearing back. And as B it's effort to craft a decline e-mail, especially with a response, and particularly if saying no is hard for them.
Ask people all the time for feedback. Make your asks specific, and your tone curious so it's safe for the other person to tell something critical. People know when you're just fishing for compliments. Examples (thread)
After a presentation you gave: "How well did you think my points landed? What would have made them clearer?"
After an analysis you completed: "How impactful was this to your team? What would have made it more useful?"
How to describe your design work in a portfolio or presentation (thread below)
Describe the problem you set out to solve.
Explain the things that made this problem interesting or challenging—what was the space of options? What were the constraints you were forced to balance?