The impulse to defend one’s work feels natural in design. But as we start to examine design reviews in the context of user-centered design, it becomes clear that defensiveness may not be the best response. Designers are much better off when they focus on collaborating with their stakeholders, listening to their feedback, and asking questions to get the deepest insights.
Last week, I gave a speech in Budapest about the importance of humility and collaboration in design. After the talk, one of the audience members asked me, “How can I stay humble and open-minded when I need to defend my work?” To which I replied, “Don’t defend your work.” My suggestion here is that designers actually shouldn’t defend their work at all.
Now, I realize that this goes against a lot of what we’ve been taught as designers. Most of us have literally spent semesters in school learning how to defend our work, we’ve listened to our greatest design idols talk about the importance of standing up to clients, and perhaps we’ve even read a couple “self-help” books on the topic. The ability to defend one’s work is not only considered a critical competency in design, but it’s one that we’ve been taught to never question. And yet, dare I say, we may have been blatantly (if not ironically) wrong all along.
It’s tough to run a productive and healthy design review from the defensive. In some cases, it can even have the unintended effect of regressing progress. But it’s an easy trap to fall into. For how much I talk about humility and diplomacy, I really wasn’t always good at it. I’m familiar with that feeling of being the young designer in the room, terrified to receive negative feedback or disappoint my stakeholders. I know what it’s like to anticipate criticism, prepare responses ahead of time, and begin thinking of replies before others had even finished speaking. Because after all, that’s what any good designer would have done: defended their work.
But with time, I stopped doing that. I stopped defending and I started listening. I started asking questions and really trying to understand the feedback that I was receiving. I started to genuinely care and express concern for what my stakeholders were saying. You could say, I started to take my own advice and actually try to understand my audience (you do know that user-centered design includes your stakeholders too, right?). And therein lies my suggestion. Rather than defend their work, designers should listen, reflect, and ask questions. That’s how you bring humility and open-mindedness into the feedback process. Don’t get defensive; get curious.
Big egos often have little ears. Don’t let your own motivations and fears get in the way of your greatest opportunities to improve and succeed. Be open to criticism, embrace change, and learn from failure. Open your ears.
I made this shift not only because I felt that my design reviews were becoming unproductive and unnecessarily stressful, but because I had noticed that the entire process was breaking down in several ways. These issues weren’t unique; in fact, they’re quite inherent to defensive reviews, and they’re precisely why a different approach is in order:
The ability to listen to stakeholders and acknowledge their feedback is not just the quality of a good designer; it’s the quality of a good leader. It’s what empowers us to create truly thoughtful, well-informed designs that are not just personal expressions of creativity, but rather are products of healthy collaboration. And when it comes down to it, a lot of this rests on one’s ability to conduct a good design review.
This lends itself to the (perhaps inconvenient, but admittedly valid) idea that despite being celebrated in design, it is wholly unproductive to respond defensively to criticism. It not only wastes team resources and erodes relationships, but it shuts out one of the most important vehicles for improving a design: stakeholder feedback.
Now, of course there are many different ways that one could attempt to solve this problem, but I would like to propose that the answer may be way simpler than we think, and it may have actually been there all along. We just weren’t applying it in the right way.
Some of the best design reviews that I’ve participated in were essentially run like user tests, but with stakeholders as the participants. That is to say, the designer took an open and collaborative approach, with a genuine desire to record feedback and probe for deeper insights, rather than to just get through the review with minimal changes being imposed on the design. They were able to do this because they operated with an understanding that UX doesn’t just serve users; it also serves businesses, and thus stakeholders.
When this kind of emphasis is placed on serving stakeholders, design reviews start to feel less like staged battles to defend or attack work and more like opportunities to collectively improve work. Opportunities to generate better outcomes for everyone involved. To do this, we really have to focus on fostering true collaboration, encouraging focused listening, and facilitating deep inquiry.
First and foremost, the feedback process shouldn’t be a one-sided exchange where stakeholders shout criticism and designers are just there to record it. True collaboration requires that both parties provide an equal amount of effort and input. As such, when a stakeholder criticizes a design, the designer should work with them to arrive at a solution together.
In other words, feedback ideally shouldn’t come in the form of mere criticism without an attempt to arrive at a constructive solution. “Here’s what I hate about the design, now you go figure out how to fix it” isn’t a constructive critique, and it isn’t true collaboration. Rather, when a stakeholder offers critique, they should expect to follow-up on their criticism and work with the designer to produce a better solution. That’s not to say that the stakeholder would literally be doing the work, but they should be able to explain themselves and really get to the bottom of their thoughts. Not only does this provide more context for the designer, but it also helps ensure that the feedback is substantial and pertinent.
Key dependency: Stakeholders need to play by similar rules for this to work. They need to maintain an open mind, properly qualify their feedback with data or sound reasoning, and build empathy and trust with the designer. It’s tough to collaborate with a stakeholder that doesn’t understand or respect design.
The designer should make a clear effort to listen to the feedback and understand what is being said. In the same way that user tests are recorded with considerable detail, stakeholder feedback should also be documented and used to steer design decisions (especially when supported by quantifiable data or business goals).
Stakeholders from different parts of the business can provide access to perspectives that designers may otherwise not consider or be exposed to. For example, executive stakeholders will often view the design on a macro level, while individual contributors will offer a peek into their specific area of expertise. Both represent major opportunities to further inform the design. But perhaps most importantly, by listening to and recording feedback, the designer can build empathy and trust with their team. They can show that they really care.
Key dependency: The designer must be empowered to make the final call on design decisions. They will be collecting information from countless stakeholders, users, and quantitative data sources. Through this, they’re best positioned to determine how feedback and data should be applied. This also greatly decreases the need to defend a design, and instead opens up room for more feedback.
The most critical step in all of this is to ask questions. It facilitates collaboration, demonstrates that the designer listened to and understood the feedback, and pushes the design review down a path of resolution. Rather than deflect criticism, the designer should ask questions that will either help them to fully understand the feedback offered or bring the stakeholder around to their point of view. This should be done as organically as possible, with a true desire to learn more about the presented point of view, rather than to only persuade stakeholders.
Questions can be related to actual design recommendations, data or perspectives that were presented, or even concerns that the stakeholder shared. The goal is to really challenge the feedback, so as to understand what the stakeholder specifically wants, and to confirm that the feedback is well-founded.
Key dependency: Stakeholders should expect to answer in-depth questions about their feedback and logic without getting upset. This can’t be seen as an indictment of one’s feedback or a personal attack, but rather as a fundamental part of the design review process. It’s what the designer needs in order to do their job.
Having taken this approach, the designer should now be able to not only understand what is being critiqued, but why it is being critiqued. And that’s where the real value comes out. Depending on the type of critique that is given, we’ll see one of two distinct outcomes:
This is where we start to see why the best way to defend work is to not defend it at all. The design will either naturally defend itself (when feedback doesn’t hold up to questioning) or welcome the opportunity for improvement (when valuable feedback is given). We never have to make a call on legitimacy, we never have to ignore critique, and we never have to sacrifice collaboration. We can simply focus on working with our stakeholders toward a better solution, resting assured that the outcome will ultimately be what’s best for the design.
In a certain way, this encourages that decisions be based more on the merit of the work itself, rather than the personal preferences or political motivations of the individuals in the room. It fosters better relationships with stakeholders, it affords designers more influence over their work, and it ensures that every opportunity is harnessed within the design. But most importantly, it’s just how we should be approaching everything in design: by getting curious, not defensive.
