How Great Designers Take Responsibility for Feedback
If you’ve been in design for a while, you’re probably familiar with that feeling when an executive looks at your work, zeroes in on something like the CTA button, and says, “This looks alright, but you should change that blue.”
Prescriptive feedback like this tends to make designers angry. They feel it signals a lack of trust, or that the stakeholder is trying to do the designer’s job and is questioning their expertise. I hear things like, “Design would be great if only I didn’t have to deal with feedback from non-designers,” or, “We need to fix the way people give feedback.”
But the reality is, feedback is kind of our entire job. We’re always subject to critique on a design team. And it ultimately makes our work better, no matter who’s delivering it.
When a comment or opinion is frustrating in the moment, or difficult to understand, it’s your responsibility to dig into it and make it useful. Expecting others to change means relinquishing that responsibility, and anyway, the only person you can reliably change is yourself.
When you resist prescriptive feedback, you’re denying yourself the opportunity to have deeper conversations that showcase your expertise and build the trust and respect you wanted all along.
Hidden insights in prescriptive feedback
Prescriptive feedback has become a four-letter word in design, but it’s usually just a disguise for a deeper, more valuable insight.
It’s not easy to critique design well, especially for stakeholders who aren’t designers or haven’t been directly involved in the project. Design is subjective, and it can take a while for people to zero in on what’s driving their gut reactions. As the presenter, with the skill set and language of design on your side, you’re the best-equipped person to steer feedback conversations and to lead stakeholders to the core of their impressions.
Let’s go back to the blue CTA button example. You could gloss over it (“It’s part of a style guide I can’t change, so I’ll just ignore it,” or, “Whatever. What do you know about color anyway?”) — or you could engage with it:
Stakeholder: “I don’t like that blue. Please change it.”
Designer: “What don’t you like about the blue?”
Stakeholder: “It’s too bright.”
Designer: “What is it about the brightness that creates a problem?”
Stakeholder: “Well, it’s drawing a lot of attention.”
Designer: “Based on our goals, we think this button is the primary CTA on the page, which is the reason it’s so bright.”
Stakeholder: “Oh, I don’t think that’s the primary CTA. I think this is.”
Aha. Now we’ve gotten to the heart of the matter: the stakeholder disagrees on the primary purpose of the design. It’s less about the blue, and more about a business objective. This is a much better starting point for a productive discussion and the next rev of mocks.
When you miss an underlying kernel of truth like that, it’s expensive to cycle back through it all later — which is why the best response to prescriptive feedback is to dig for deeper understanding.
Facilitating better feedback conversations
Designers can take responsibility for feedback by setting up the conversation, asking questions, and sharing the language of design to strengthen long-term relationships with stakeholders.
1. Frame your feedback session
Start the conversation by grounding it in objectives, so people know what type of feedback is most helpful.
It might be as simple as saying, “Today we’re only looking at the structure of the webpage. The type and visuals are just placeholders.” But you can go deeper by framing the problem, user needs, and project goals.
On the Asana design team, we use a template to set up our internal critiques:
The problem:
- What problem(s) are we trying to solve?
- Who is the target customer? What are their needs?
- What are the project goals?
- What did we discuss last time?
Where I’m at in the process:
- Are we in the Discover, Define, Develop, or Deliver stage?
- Are we diverging or converging on a solution?
The type of feedback I’m looking for:
- What feedback would be most useful to advance my work?
You can also ask a stakeholder to deliver feedback using the Do/Try/Consider framework, which helps you determine their “volume level” and helps you select and prioritize which comments to incorporate into your work:
- When they say, “Consider this,” it means, “Think about this idea.”
- “Try this,” means, “Please, actually go try this out.”
- “Do this,” is a directive — make this change.
It’s pretty self-explanatory, but the extra clarity can help avoid misunderstandings.
2. Ask questions
Guide stakeholders with questions. They might not know why an element feels wrong — they just feel it. So, find out: is it the color? The position? Its very existence? And most importantly: why do they feel the way they do?
Open-ended questions are best, such as:
- “What bothers you about X?”
- “Why don’t you like it?”
- “Why do you feel that Y is a better solution?”
- “Why is the blue/red/black a problem?”
- “Why do you feel it’s too bright?”
- “Why is ‘too bright’ an issue?”
You can also relate your questions to the project’s goals:
- “As a reminder, we’re building the feature for [this reason]. Do you feel it’s meeting that goal? Why not?”
- “Have you thought about this in terms of [specific customer persona]?”
- “Does your feedback relate to a specific type of customer, or is it your own opinion?”
Once your line of questioning helps you identify the real problem, two potential paths can emerge:
- You reach that moment when you understand the underlying issue, and you’re excited to try some fixes and solutions.
- You’re able to start a new conversation about the original requirements of the project, or use your expertise to explain your original choices and directly address the stakeholder’s core concerns.
Great questions help stakeholders feel heard, while clearing the way for you to act. For more inspiration, check out the 5 Whys framework, which we use at Asana to improve processes.
3. Introduce the language of design
Leaning into feedback can, in theory, be a virtuous cycle and a way to educate stakeholders about design. If you bring new terms into the mix, executives will learn a lot about how you think about things.
Can you link feedback to words like layout, typography, color, alignment, repetition, rhythm, and pattern? Are there systems your team uses to guide decisions? For example, in our blue button story, you might say, “I made the button this color because it matches our system palette, and this is what we use for all primary CTAs.” Don’t assume they know that.
Sharing your expertise builds trust, and when stakeholders know you have a solid rationale behind your design decisions, you’ll likely get less subjective feedback
4. Follow up
You may already be back at your desk before you realize that you don’t understand a piece of feedback. The moment to ask questions in person has passed.
This is perfectly normal. We won’t always catch everything, and it’s okay to follow up with the stakeholder and ask for clarity (though norms and company cultures can vary).
Finding clarity is less about catching issues right away, and more about not spinning your wheels in frustration. The general rule is that if you don’t understand feedback, do your best to find out what it means.
5. Show early and often to avoid big surprises
You can’t control the feedback you receive, or how it’s delivered. But you can control when you show your work. Share it early and often to bring stakeholders on the journey with you, and to avoid getting a heap of feedback all at once.
Work feels personal, and sharing it often can be scary. Critique is a double-edged sword: it can sometimes make you feel like you’re doing bad work, but it’s also exactly what makes your work stronger. That’s why it’s worthwhile. Being part of a team is amazing because you don’t have to figure everything out on your own, and your work is a byproduct of all the feedback you accumulate over its lifespan. So go and get as much of it as you can.
👋 Interested in finding out more about Asana? We have a neat site up at https://asana.design with a little about who we are and what we do. We’re hiring Design Managers in our San Francisco office, and Product Designers in San Francisco, New York, and Vancouver. Asana is the #1 Best Workplace in the Bay Area in 2019 for the second year in a row, and a 2019 Best Place to Work in NYC.
If you enjoyed this post, you might want to follow our publication for more stories from Asana Design
