It’s fairly common to see designers complain about the poor quality feedback they’ve received from stakeholders or clients. “They literally told me to make the logo bigger!” they might joke, or, “They told me ‘it just didn’t feel right’ but couldn’t explain why. What am I meant to do with that?” Our response is usually to empathize with our poor colleague — after all, we’ve all been there before — and laugh at the stupidity of clients.
This sort of interaction can be a great bonding moment with a fellow designer. Still, as an industry that’s meant to be great at empathizing with people we might be missing something here, especially if we find ourselves getting this sort of feedback fairly regularly. Maybe it isn’t all the fault of the stupid colleague or client. Perhaps it’s also got something to do with how we present our work, the questions we ask, and when we choose to ask them.
What’s Going Wrong
I’ve sat through more bad design presentations than I care to think about, with designers walking through every single design decision they’ve ever made.
“First, I tried this. Then I tried that. I didn’t like how this worked, so I tried this other thing, and it felt better.”
It’s like sitting through a slide show of somebody else’s baby pictures or holiday snaps or a child coming back from school and talking about the exciting finger painting lesson they just had. Super meaningful to them but pretty dull for everybody else.
So is it any wonder when the rest of the people in the room tend to switch off their critical faculties — after all, no business problems are being shared or important decisions being made — and join the designer on a step-by-step tour of their Figma history, only to be jolted back to the room with the immortal words:
“So what do you think?”
At this point, the executives snap back into action. They’ve been asked what they think, and if there’s one thing executives love doing, it’s giving feedback. So they’ll jump in with a list of things they don’t personally like:
“That looks too big. This looks flat. I don’t like this color. Can you make this area pop a bit more?”
Opinions, opinions, opinions. That is exactly what the designer didn’t want.
So, how do you break this cycle?
Framing The Request For Feedback
Instead of presenting a linear case study that will show every design revision, the first thing you need to do is frame the problem — essentially, to explain what’s wrong with the current design and what problem you are attempting to solve with the new version. After all, design is meant to be about problem-solving rather than pretty pictures, right?
If you would like to show a few dead ends along the way and ramp up the drama, that’s fine. However, you will need to explain those in terms of the problem being solved rather than saying vague things such as “This typeface didn’t work” or “We needed a better color scheme,” as such things will encourage subjective opinions.
Instead, when you present the final design, engage with the stakeholders on a strategic level and explain how the new design solves the problem at hand. Or even better: Explain how you’re going to test/prove how it solves the problem and by how much.
“We’re going to push this release out next week, and we will come back to you with some figures by the end of the month.”
This is much better than a vague, “What do you think?”
Be Specific
If you are genuinely looking for feedback, be specific about what kind of feedback you’re looking for. Are you looking for comments on the visual style, or are those already set through your design system/brand guidelines? Often you’re not really looking for feedback as much as seeking to understand whether they agree that this solution solves the stated problem. So if that’s what you’re looking for, ask them.
If you think there may be contentious issues with the design, flag these up in advance. So, for instance, rather than waiting for the Chief Marketing Officer to ask about the opt-out checkbox, let them know that it’s been changed to opt-in to comply with GDPR.
If you receive feedback, don’t always assume you’re being asked to change something in the design. It’s perfectly reasonable to receive the feedback as a gift (free advice) and let people know that you will take into consideration what they said.
If you’re unsure whether the feedback is a request, don’t hesitate to clarify. If that person isn’t the DRI (directly responsible individual), let them know that you’ll run it past the DRI for final approval. Execs are often just trying to be helpful, so it’s your job to frame the problem and channel their feedback in the correct manner.
Don’t be afraid to say:
“We’re not looking for feedback on the visual language at the moment, but we would love feedback on X!”
Whatever that X may be, of course.
Don’t Seek External Validation. Ask For (Real) Feedback
Designers often ask for feedback at the end of a presentation when it’s really not necessary. It’s perfectly reasonable to frame a presentation as an update and state something along the lines of:
“We’re not looking for feedback at this stage.”
Designers desperately want to be appreciated, so the request for feedback at the end of a presentation may be a clumsy attempt to solicit some praise.
You say:
“What do you think?”
When you really mean:
“Please help support my fragile ego and tell me how great I am!”
Sadly, this subconscious need for external validation regularly backfires, and you’re left feeling worse rather than better.
This is a key distinction I see between junior and senior designers. Junior designers often ask for feedback in the hope they are right and will get a pat on the back. By comparison, more senior designers genuinely hope they’ve missed something because they realize good feedback will help them grow.
As such, the correct answer to such feedback is:
“That’s super interesting — tell me more!”
That would be much better to say rather than blurting out a list of reasons why the feedback is wrong and you’re right.
Learning From Our Mistakes
As an expert, you can tell people their ideas will not work or are going to backfire until you are blue in the face, and they still won’t listen. Instead, the only way most people learn is to go ahead, experience the failure in a tangible way, and then start their own learning loop.
While you want to avoid the “told you so” conversation, you do need to be visible when that lightbulb goes on so they know that the next time you flag up an issue, they could avoid a lot of pain by listening to what you say. Usability testing is a great way to instrument this learning process.
Sadly, designers are very good at flagging up all the reasons why something won’t work and end up feeling frustrated when people don’t listen. However, we’re less good at follow-up. As such, the ultimately responsible person often never sees the problem occur because it’s obscured, not directly experienced, or hidden in the data, and they don’t see you as somebody who could help them avoid similar mistakes in the future. Instead, we get angry with stakeholders who don’t heed our (often) very good advice, which ironically makes them even less likely to listen to us next time.
As a start-up advisor, I regularly see founders make easy-to-avoid mistakes. I’ll always flag these up as I think it’s unfair to see people hurt themselves and their businesses unnecessarily. However, you often need to let them make those mistakes in order to learn.
Show Your Work Early And Often
This last problem is a bit of a biggie. I see far too many designers who only want to show work they think is 95% done and then get frustrated and defensive when asked to make changes. You can understand why. It’s like getting to the finish line of a marathon, only to be told that the race has been extended by another ten miles. It’s exhausting and disheartening, and you’re not entirely sure you have enough “gas left in the tank” in order to continue.
This behavior is often tied up in a designer’s psychology and sense of self-worth. We don’t like receiving criticism — I mean, who does? — as it often feels like it’s us who are being criticized rather than the work we did. So we hide away until we’re sure we’ve got it nailed before stepping out into the blinking sunlight, only to have some mean executive crush our dreams.
The answer is annoyingly simple.
Rather than waiting until you’ve reached perfection, get comfortable showing work in progress — messy first drafts you know are going to solicit feedback.
That way, when you get said feedback, you’re not going to be shocked or surprised, and you still have enough energy and will to make the necessary changes. So rather than being precious, good designers show their work early and often! They bring execs along with them on the journey.
Just kill the “big reveal” moment — you don’t need it!
Conclusion
Ultimately feedback is a gift. It allows us to produce better products with a higher chance of being accepted by our clients, partners, and peers. In order to get useful, actionable feedback, designers need to get comfortable showing work early and often; they need to get better at presenting the business case for their work; and they need to get better at asking the right questions and guiding the sort of feedback they want and need.
The best designers know this. Good designers hope to be proved right. However, great designers want to be proved wrong. Why? Because it’s the most effective way to learn and get better.
Further Reading
There are lots of great resources out there on design feedback! Here are a few of my personal favorites, including a few excellent articles from Smashing Magazine.
A good place to start would be the book Discussing Design: Improving Communication and Collaboration through Critique by Adam Connor (@adamconnor) and Aaron Irizarry (@aaroni).
Also this article on async feedback “Asynchronous Design Critique: Getting Feedback” by Erin Casali (@Folletto) is very good.
As an aside, I’d love to see more designers go into meetings saying something along the lines of “We believe this improvement will drive £ 1 million in additional revenue over the next three years.” rather than “Making this design change is the right thing to do.” which happens more often than not. One of the reasons I love the @GrowthDesigners community (Growth Designers) is that they represent designers who have decided to focus specifically on one or (arguably) more of these areas and can articulate and demonstrate the direct impact they have on the business as a result.
Nick Stamas’s (@nickstamas) thread for product designers lists ten useful (but hard) truths on design, check it out!
“How To Design Outstanding Feedback Loops,” Loren Baxter (Smashing Magazine)
“How To Respond Effectively To Design Criticism,” Andrew Follett (Smashing Magazine)
This piece starts with a quote from Winston Churchill, and I fully agree with it: “Criticism may not be agreeable, but it is necessary.”
“How To Give Effective Feedback Remotely,” Joshua Mauldin (Smashing Magazine)
This is an excellent new piece (published in 2022) in which the author shares many valuable hints on how to give and receive better feedback when working remotely.
In this article, Andy Budd shares his way of requesting feedback: rather than sharing a linear case study that explains every design revision, the first thing to do would be to better frame the problem.