Hi! I am starting a new job as a Senior PM and will be my first time leading triads (Development + Design). How do PMs typically share feedback with Designers? Having spoken to a few designers, it seems that designers don’t like microscopic level feedback and typically have a strong PoV on whatever they come up with.
4 Likes
Do you know the line among fashioners and PM? Guidance relies vigorously upon that. In certain groups, originators take full responsibility for UX and PMs just spread out necessities for usefulness. In different groups, similar to mine, PMs basically fabricate 90% of the UX and the creator fills a for the most part imaginative job - styling, design, shading, typography, and so forth Furthermore, a few groups are some place in the middle of those two.
3 Likes
I accept that originators ought to be given a major say in creating the item arrangement. I have been important for associations where creators are involved very early right from the issue definition stage. Have you seen any benefit of PMs possessing a huge piece of the plan?
3 Likes
I wasn’t endorsing either, simply had to know what the circumstance at present is for the group you’re infusing into. The manner in which you would move toward that relationship would vary depending on which side of the range things fell.
2 Likes
Few specific tips when offering feedback for mockups.
1. Align the ratio of positive and negative feedback with your real opinion
Be authentic about what you liked in the mockup and start with that.
This creates a safe space so that the designer becomes a better listener to the negative stuff you’re about to say.
And it puts the negative stuff in a perspective that’s in line with their weight in reality.
If the mockup is 70% good, but 100% of the feedback is about what can be improved, then you are making the designer doubt themselves unnecessarily.
2. Go one level up
Don’t stay in the solution space. Don’t tell them “Perhaps add a button that does this here”. Tell them what’s the value of that button. Which behavior is it intended to change? What’s the damage of not having it? What’s the weight of the problem it would solve?
3. Don’t frame feedback as a question
Don’t ask them something along the line of “have you thought of adding a button that does this here?”
This gets them defensive as they have to start their answer with “no”.
4. Provide feedback after processing all thoughts, instead of "as a thought come up"
Don’t send them multiple messages on Slack as you go through the mockup.
Write down in a draft whatever comes to mind as you go through the mockup and edit at the end.
And if it’s a presentation then the above still applies.
Write notes and provide feedback at the end.
Don’t just say anything that comes to mind as it comes to mind.
The effort you put in conveys respect to the designer and builds trust.
5. Don’t give feedback if you don’t have the energy to get into specifics
Don’t provide the type of feedback you’d hate to receive.
Don’t say stuff like “this is half baked”, “this is not good enough”, “the feature is not intuitive”.
Usually, this happens when the person giving the feedback has no energy to invest.
The person giving the feedback has good intentions as they think that any attention is better than no attention. But this type of feedback could cause more damage than giving no feedback.
The potential damage is that the recipient doubts themselves unnecessarily, and are left frustrated that they don’t know how to handle the feedback.
They may think that the issue is with them, and that would prevent them from asking a follow-up question.
It’s sort of like passive gaslighting as the feedback could be interpreted as having an aura of “it’s clear there’s an issue there and you should spot it. So if you ask me a follow-up question it means you are not professional or experienced enough”.
6. Ask the designer what is the maturity state of the mockup and what type of feedback they want.
If maturity is super low then you know you can probably be more aggressive in your feedback.
On the other hand, if the CEO already approved the mockup then the 2nd question becomes more important.
Do they want feedback for microcopy? Look & feel? Functionality? First impression no context type feedback? Everything?
Feedback should be unbiased and we tend to think that asking these questions would contaminate the conversation.
But there are different levels of feedback, and giving the wrong level of feedback could be a waste of energy for both sides.
And saying we want “Microcopy feedback” doesn’t cause too much bias.
So offer some high-level safe specific terms in your question to assure the designer that their answers wouldn’t contaminate the feedback.
3 Likes
A few thoughts, from someone who’s worn a PM and UX hat at various times in my experience, UX person is responsible for creating a coherent design solution that helps achieve a business or user goal - sustainably (requires reasonable Eng/etc resources over time) So present any qual or quant data you have about the 1) coherence 2) business/user goals 3) sustainability that adds to a rationale for a different solution. This should be delivered as helpful information to make the design more successful.
- “I’ve seen most customers use the term X where you’ve written Y, so I think it’s more likely that they’ll understand this if we use X.” (helps to state things probabilistically when you aren’t 100% certain)
- “The data shows that function X is getting used 3x more often than Y, so I think we should make X be the default on this dropdown”
If you don’t have data, and just have an assumption, state it as just an assumption. If your assumptions aren’t aligned, get it in front of customers. State things in tradeoffs, i.e.
- “We could add support for that edge case, but it would add 3 days of build time, and we’re hoping to get this out by next week. Is there any smaller-scope solution considering only 1% of users are in that edge case?”
- “We’re behind on our numbers this quarter, so I think we need to make this banner more prominent, even if it may annoy some customers - we can keep an eye on the metrics to make sure it’s a healthy tradeoff”
Embrace that it’s a back and forth discussion. Your initial feedback might be off, so take the time to discuss and find anywhere you’re misaligned and why - this will often feel too long, but bear with it, it’s much better than building the wrong thing for to work, it really helps align incentives if the UX/PM/Eng pod are all being graded on the same metric/goal. Also helps if qual/quant data is easily accessible by all.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.