Giving and receiving design feedback is tough. It’s constantly brought up in discussions about design best practice. Some designers fear it, others crave it. Some people think they’re Steve Jobs and they have the right to curb stomp what they deem “bad” ideas. (no offense Steve!)
I’ve been on the receiving end of some great feedback that pushed my work forward and really made me think about my work in new ways. I’ve also gotten some feedback that left me feeling confused, unmotivated and directionless. And I’ve given both.
In the majority of interactions I’ve witness, designers, leads, product managers and stakeholders come from a place of wanting to improve the work, push things forward and bring about confidence in the team.
Sometimes though, that feedback is ill-aimed, unconstructive, irrelevant, antagonistic and it’s those interactions which can break the spirit of the designer.
Be tough, but constructive…and honest
This is said so often, it’s almost trite. But what does it mean to be constructive?
1. serving a useful purpose; tending to build up.
I’ve gotten feedback where I could tell the other designer was holding back because they didn’t want to hurt my feelings. Thank you for sparing my feelings, but you’re not pushing my work forward and that’s what I need. Should you be kind? Absolutely. Should you say what you really think? Yes. Figure out what you really want to say and come from a place that tends to build up. If you’re really trying to improve the work and inspire confidence in your fellow designers, then this should come somewhat naturally.
Designer #1: What do you think of my color choices in this UI?
Designer #2: I like what you did with the header and nav, they’re clean and to the point. (positive reinforcement of correctness). It looks like you may be overusing your primary action color. You’re using it here, here and here which could detract from your intended workflow. Try reworking that aspect.
Know who you’re receiving feedback from
Stakeholders, clients, other designers, leads, users… they’re all going to give feedback differently. When you ask for feedback from a stakeholder, expect them to be thinking about a different set of problems than you would. They’re not going to comment on your button radius or use of grid.
It’s important to ask questions that are in that person’s wheelhouse and understand that you may receive feedback that is NOT in that person’s realm of understanding.
Designer: Now that you’ve been able to look over the designs, do you feel the UI for the app aligns with your overall brand? (question the client could actually answer)
Client: Yeah, you’re using our colors properly and it feels like the rest of our marketing site but the tone of the copy doesn’t quite feel like us yet. Maybe we can work together on that.
Ask questions first
If you don’t understand the problems the other designer is trying to solve, how can you give useful feedback? They’ve been thinking about those problems for a while so what right do you have to dive in with strong opinions without at least a basic understanding of the problems and goals. Start by asking questions that put you in the minds of the users, the designers and the business.
Designer #1: The workflow in my wireframes feels a bit off, what do you think?
Designer #2: Well, what mindset are your users starting with? Can I see the user journey and user research summary? What problem does this workflow solve and how do they currently solve it?
Once you feel like you understand, go for it! Which leads to my next point…
Make sure you have the time
Don’t do flybys. If you don’t have time to sit down, understand the problem and really give your full attention to the designer, then come back later when you have time or schedule a time to work through it with them.
No one likes off the cuff feedback. It makes the recipient feel like you don’t really care and even worse, it could lead to bad recommendations. So make sure you have at least a few minutes to look through the work thoroughly. Don’t feel like you have to give an opinion every time you’re asked just because. The designer will feel better if you’ve shown them the work is important by carving out time to look at it with them.
Don’t say it unless you have a better suggestion
If you can’t suggest a better way to do it or at least point someone in a better direction, then don’t bother saying it.
“I don’t like it. It just doesn’t look right.”
“Your buttons look old school.”
“Everyone is doing conversational UI, this looks like a copy.”
Maybe you’re right. But what is the designer supposed to do with comments like this? Try to think of how it could be done better, differently, more creatively and ask questions to get them to see that if you need to.
“Something doesn’t feel right about this part, have you tried looking at the proximity each set of elements and regrouping them? It might help users to more quickly find what they’re looking for.”
“The button styles don’t quite align with the design system we’re using. Take a look at the brand guidelines and design system we’re using. That should help make things feel more cohesive.”
“There are a lot of conversational UIs out there and there are some apps that do it really well. Have you tried doing an audit to look at their strengths and weaknesses?”
To steal an old cliché:
If you can’t recommend a better or different way to do something, don’t say anything at all.
Are you solving for business, tech, users or everything?
If your feedback is based on a single view, you’ll invariably sway the work in that direction. When giving feedback around features and broad parts of the experience, it’s important to understand the impact on the business, the benefit to the users and the technical effort involved. Can these three areas be friends? Yes and you need to understand the implications on all three fronts.
A feature in a dry cleaning app that detects when your laundry basket is full, contacts a dry cleaner, schedules a pick up and alerts you when your dry cleaning is being delivered may be the most awesome feature for an audience that really hates wrinkled shirts but the impact on the business may be minute and the technical effort astronomical.
All features and design decisions are not created equal. Make sure to look at things from all facets before making sweeping recommendations.
Let the designer be the designer
“Change the color to blue. No, lighter blue. Now move it down 10px. Wait, not that far. Looks good. Now let’s look at the nav…”
You just turned a potentially awesome designer into a pixel pusher robot with little interest in their work. They’re now designing to please you instead of working through the problems themselves and growing.
Guess what’ll happen next time they’re designing something. You’ve just inherited all of the design decisions yourself. If you’ve given someone the responsibility of designing an experience, let them take responsibility and have the freedom to make their own decisions.
You can’t hit the ball for the batter in a baseball game, but you can teach them how to swing and position themselves for a home run. </endSportsAnalogy>
- Ask yourself if this feedback is going to improve the designer before you give it.
- Give the type of feedback you’d want to receive.
- It’s okay to say something harsh, as long as you’re recommending a better or different way to do something. It is art after all.
- Ask questions. Get in the mindset of the designer, users and the business—then give your feedback.
- Don’t do flybys. Don’t give feedback off the cuff. Take the time to give good feedback and suggestions. If you can’t, then schedule a time to do so.
- If someone has the responsibility of designing an experience—let them be the designer. If they’re having trouble, help them. If they can’t do it, find someone who can.
I hope this helps. Some of these lessons were hard learned. I’ve broken people—unintentionally. Be patient. Help the designers around you. If they’ve asked for your opinion, you’re now a mentor. And if you give great feedback and help them work through their problems, you’ll win, they’ll win and you’ll make some amazing friends in the process.
Thanks for reading. If you enjoyed it, feel free to dish out a clap. If you didn’t, let me know in the comments. Always looking for a friendly discourse.