How to give constructive design feedback over email
Tips for designers and non-designers that will make everyone happier
During the product development process, designs are exposed to a lot of feedback and criticism. Very few will comment on an engineer’s code style, or a bizdev’s outreach process, but everyone will chime in on how they feel about a new design. This is great — the more feedback a design receives, the more refined it will be when it ships.
The caveat here is that a lot of feedback is done over email now, and it’s easy to jot down your feedback without much thought. That sucks, since giving constructive feedback online requires more thought than it does in real life: what you can’t communicate in tone and body language, you now have to consciously arrange into words. Instead of a back-and-forth conversation with questions and clarifications, email also arrives all at once, and when done poorly, it’s hard not to interpret it as a big ball of negativity — even if the sender meant well.
I hear this a lot: “email feedback sucks; phone? IRL?”, but I think that’s a cop out. I believe we can have productive conversations through written words. Here are some of the things I think about when I send feedback over email:
1. Get on the the same page
Before you start typing, make sure everyone has the same expectations for this project: Are you aligned on the scope, goals, and terminology? Is it clear that it’s a non-functional prototype? Differing expectations cause conflicts.
Try to mention what you expected at the beginning of the email — it will help prevent a lot of conflict (e.g. “I was expecting this prototype to be code complete since we’re thinking of shipping on Friday, so the feedback below is based on that assumption…”).
2. Talk about what you felt, not what you think the user will feel
Bad: “I don’t think a user would ever see those share buttons”
Good: “I didn’t share this link, because I couldn’t find the share buttons”
It’s easy to start talking about what you think the user will feel or your ideal use case. That’s hardly constructive, because everyone has a different ideal. Instead, think of feedback like a diary. Record things you thought and felt in response to the design. You can argue defensively for hours about what you personally view as the ideal use case, but you won’t argue with what someone felt or saw or did, but will instead have a more constructive conversation about the reasons why.
3. Use past tense, not present
Bad: “It doesn’t make it clear that this happened”
Good: “It wasn’t clear that this happened”
It’s hard to believe, but this makes a whole lot of difference in the way your feedback is perceived. Speaking in the past tense will avoid conflicts around what we think IS, and will focus the discussion on why something made someone feel a certain way.
4. Question constructively by asking for opinions, not challenging them to convince you
Don’t ask aggressive, challenging questions like: “Why would the user ever do that?” The word “ever” makes the question a few steps short of “why the fuck would the user ever do that?”, and puts people on the defensive.
Instead, ask for their opinion on the matter: “How do you think the user would know how to do that?” Then you can understand the thinking behind and focus the discussion on higher level motivations and goals, rather than specific executions. Look for a constructive conversation, not a final answer.
5. Try to be specific, and avoid subjective words
Bad: “The position of this is kind of weird”
Good: “I’m usually used to seeing this on the bottom, but this design is different and I’m not used to it.”
Because all feedback is subjective, it’s hard for others to understand what you mean when you use subjective words that mean different things to everyone (e.g. what’s ‘weird’ to you may not be to me). Try to use objective words that are not open to interpretation to describe your subjective feelings.
6. Don’t be dramatic
Bad: “I had NO idea what this icon was — it looks way too much like an ant biding its time.”
Good: “I saw this icon but it took me a while to understand what it represented. It reminded me of an ant biding its time.” (Optionally add a LOL at the end.)
Use words carefully. What you normally communicate via body language and tone will need to be converted into written word. Hyperboles and exaggerations can and will upset. Softening your language with words like “maybe”, “sort of”, or “a little” may help as well. Leave caps lock off, and resist the temptation to bold, italic, and underline.
7. Give the design some time, and ask yourself if that email needs to be sent now
Let the design sit for a bit. Often it’s good to assess your gut reactions, but let them stew for a bit before you comment on them. Feedback solely based on gut reactions works best for 1-time experiences like marketing and onboarding, but aren’t as accurate for parts of the product that are used/seen day to day. Simulate the conditions of daily use by looking through the designs several times over a day.
Also, don’t send emails at sleepy and cranky hours, e.g. 2AM.
After working at a startup for a year, I’ve found that all feedback is subjective — in the end, it’s a couple of people making assumptions based off their personal experiences. When conveyed poorly over email, it often results in conflict. This isn’t unique to startups: many businesses and teams could be more efficient and happier if we learned how to use email to our advantage — not just hide from it.
I’ve also realized that designers can play a big part in improving this process: we can try to foresee and answer questions that may be raised based on our past experience with your stakeholders, and teach teammates design vocabulary so they can communicate more specifically about our work.
This is a problem that can be fixed. Make a few changes to the way you write your emails and see how it goes — you might be surprised at how setting the tone differently can affect you and your team’s happiness.
