Designers! We’ve all had the experience of showing our work to someone — usually someone with more power and clout than we have— who looks at our work, shrugs, and says “I don’t like it.”
It could be a client, or a manager, or a colleague. But it’s happened to every single one of us. It’s so frustrating. There’s no acknowledgement of our hard work, no understanding of the decisions we’ve made. And worse, there’s no way of knowing what you should change to make them like it.
It’s easy to blame the stakeholder, of course. They should be giving better feedback! They don’t understand my value! They aren’t listening when I explain my choices! How can I create something they do like if I don’t have clear direction?
The unspoken question in your mind is probably something like: well, how do I make you like it?
Sometimes, this question even starts to cramp our design work. It becomes easy to fall into the trap of saying “I’m not going to design this way, because my product manager doesn’t like it.”
No, no, no. “My PM doesn’t like it” is not useful on its own.
I’ve got some news for you: this lack of useful feedback is not our stakeholders’ problem. The ways we talk about our work in design-only critique aren’t things they have insight into. The language we use to explain, rationalize, and defend our work isn’t language they use day to day. So we can’t blame them for not knowing how to talk about design intelligently. As designers, this is our problem to solve.
We can’t blame our stakeholders for not knowing how to talk about design intelligently. As designers, this is our problem to solve.
First, we can avoid this situation in the first place by talking about our work with more clarity and purpose; next, we can learn to solicit better feedback from colleagues; and finally, we can spread a culture of better design feedback throughout our organizations.
How to avoid getting this feedback
Start with goals
I’ve seen so many feedback sessions where designers open by showing their work, and asking “what do you think?” Or, “I’m open to any feedback you have.”
This doesn’t set the the session up for success—it practically invites “I don’t like it.”
Remember Design Critique 101: start with the goals of the project. Mention those goals at the start of every formal design review. Even if you’re meeting with your product manager who created the goals of the project, remind them before you show them your next iteration. If you need a structure for this, check out Jared Spool’s Short Form Creative Brief.
Why do this? To make sure everyone has the same goals in mind. Or as Jared Spool puts it, to make sure everyone is actually working on the same project.
Sometimes the goals are obvious, but sometimes there are goals the PM has only in her head. Or maybe the PM had a recent stakeholder meeting where the project goals had to shift, and she hasn’t shared that with you yet. Or maybe there are people in the room who aren’t aware of the goals at all.
Regardless, it’s a smart idea to start every design review by stating the goals and making sure everyone’s in agreement. Even if everyone is already on board, it sets a tone and frames the conversation.
To put it another way, it becomes harder for your PM to say she doesn’t like that color blue when you’ve just reminded her that you’re focused on increasing user acquisition by 10%.
Structure the conversation
I’ve witnessed design reviews that were run by a product manager, even though the designer was in the room. This isn’t good —it disempowers the designer to feel ownership over their work, and is a missed opportunity to showcase the thought process that went into the design.
Additionally, when the PM presents the work, it removes an opportunity for the designer to practice articulating the goals of the project. Everyone on the team should be able to do this, not just the product manager. Alignment on goals is everyone’s responsibility, and everyone should be able to articulate them.
As the designer on the project, design review is your meeting, regardless of who created the calendar invitation. You should be on the hook not only to present and discuss your own work, but also to structure the session in a way that solicits the most effective feedback.
In other words: If your work is being discussed, you should be presenting your work, and it’s your meeting.
If your work is being discussed, you should be presenting your work, and it’s your meeting.
(Caveat: if it’s an executive-level review, the product manager, or someone above you in the food chain, may choose to discuss the work whether or not you’re in the room. This can be all right, depending on the type of review it is.)
Here’s some ideas for structuring the conversation for the best possible outcome.
- Open by restating the project goals, and asking for the feedback you want. If you want visual design feedback, ask for it; if you’re specifically not asking for visual design feedback because that’s still in flux, say that out loud. If content isn’t final, say that too.
- Give yourself a time limit, and stick to it. This is a feedback session, not just a presentation, so make sure you give your stakeholders more time to discuss your work than you spend presenting.
- Don’t present directly from Sketch. This might be okay for designer-only critique depending on your team, but up your game for stakeholder meetings. All that panning and zooming in a formal meeting is distracting for many stakeholders.
- Present from a tool that has inline comments. I once managed a designer who presented from Zeplin, and recorded the feedback in Zeplin live during the meeting. This is smart—it allows direct commenting on certain areas of the design, and also demonstrates to the stakeholders that their feedback was heard and recorded. It also allows other stakeholders, ones who may not have been in the review, the opportunity to see those comments. And bonus: the designer gets to track all of the feedback in the same place.
- Ask stakeholders to hold their thoughts until the end of your presentation. Provide paper (I like post-its) and pens so your colleagues can write their thoughts down — this relieves them of the anxiety that they might forget some critical piece of feedback. And it helps get everyone off their laptops.
- Request that it be a laptops-down meeting. You can’t give thoughtful design feedback when you’re looking at your own screen. This can be a delicate conversation to have; I often indicate that it’s a laptops-down meeting in the invitation, and remind people at the beginning of the meeting, so the conversation is less awkward. (Suggested language to use: “Good morning, thanks for coming. Reminder that I’d prefer this be a laptops-down meeting if possible, so I can get the most effective feedback.”)
What to do when you hear it anyway
Sometimes, even when you do everything to avoid hearing “I don’t like it,” you still get it anyway.
What to do? Ask them why. The trick is to come across as receptive to the feedback, and curious to learn more. Here are some phrases to use.
- “Ok, thanks for letting me know. What don’t you like about it?
- “Ok, thanks. Tell me more about that.”
Use your “five whys.” Go deep until you understand the root of the problem. Prompt them if you need to. The conversation might go a little bit like this.
PM: “I don’t like it.”
You: “Ok, thanks. What don’t you like about it?”
PM: “It feels too… busy.”
You: “Ah, I understand. The project goals mean that we have to have a lot of information on the page at once, and it’s a challenge to figure out how to get it all on there.”
PM: “Yeah — I guess I just don’t know where to look first.”
Boom. You’ve just identified that you have a visual hierarchy problem. That’s a problem you can address!
Use frameworks to spread a culture of good critique
Many years ago, I was working on some enterprise software, partnering with engineers who had some very strong opinions. They had built the software from scratch, without a lot of input from design, and weren’t willing to implement design decisions that they didn’t pick apart and explicitly approve.
I wasn’t experienced enough to know how to solicit better feedback from these engineering stakeholders, and the only feedback I got from them was “I don’t like it.” And yes — I tried to dig deeper, but I was iterating in circles.
Six weeks into the job, I was so frustrated that I started polishing up my resume.
Thankfully, my manager at the time stepped in. She ran a workshop with the designers and engineers to create a framework and structure for giving and receiving better design critique. She calls it Embodied Critique; you should go check it out.
Ever since then, I’ve been a huge fan of creating and socializing critique frameworks. Frameworks give you hooks to hang your thinking on. And better, if all people in an organization understand the framework, it becomes an effective, meaningful shortcut in your design reviews.
Personas are a type of critique framework. If you can center the conversation around the human being using your software, and if you know enough about them to understand what they care about, you can often have a really great discussion around a given design approach. Personas let you answer questions like:
- What does your target user’s day look like? Is their workflow interrupted a lot? Design for an interruptible workflow.
- What’s the median age of your target user? A lot of people over 40 have eyesight issues — make sure your color and font size choices take this into consideration.
- What’s your user’s understanding of industry jargon? Stakeholders love to iterate on content. Frame your content choices in terms of your persona’s fluency with the subject area.
The most recent framework I’m enjoying is Tenets and Traps. Developed by folks at Microsoft and elsewhere, this approach tries to put a cohesive framework around questions like:
- What are the well-established tenets that make a design “good?”
- How do we recognize good design when we see it?
- What are the common UI traps that can degrade these tenets?
The best thing about critique frameworks: they communicate that design operates with rigor. We aren’t just making our decisions out of nowhere, or from our “gut.” Frameworks create a process that everyone can participate in, and assist in understanding how we make decisions.
The best thing about critique frameworks: they communicate that design operates with rigor.
Pick a framework. Practice it within the design team, see how it goes, and then try rolling it out to the entire department or company.
So—did you like it?
You know I’ll have followup questions! Did you try these ideas out? Did they work? Are you getting fewer “I don’t like it” comments?
And if you hear “I like it,” what happens if you say, “Thanks, why do you like it?”
And what thoughts and ideas do you have to solicit better design feedback from stakeholders?