Designers, own your feedback
“Everyone seems to have an opinion about my design”
“This feedback is too tactical for where we are in the project”
“Why am I receiving design feedback from the developer?”
“This feedback doesn’t even make sense”
“I wish I had received this feedback earlier”
“How am I supposed to address all this feedback by tomorrow?”
There is this common belief in our industry (and a running joke, quite frankly) that designers hate feedback. Understandable. As a designer, getting comments about your work in a feedback session can feel like putting yourself in a vulnerable position.
But comments like the ones aforementioned don’t help. In fact, they show a serious misunderstanding of the digital product design process and potential immaturity on the designer side.
Feedback, dear designer, is part of our job.
Feedback makes the work stronger
The best way to make a design stronger is by testing it. Testing a solution can get it closer to being bulletproof. And “testing” here can mean many things: (1) testing it with users in a usability session, (2) testing how the flow is going to work by creating a prototype, or (3) testing whether a certain idea makes sense from a business and technical perspective by sharing the designs with product managers and developers.
Sharing is part of our job. We’ll always be subject to critique by other team members, and that is a key component of the iterative design process. If done properly, design feedback sessions make the work better, help anticipate mistakes, identify misalignment across teams, and prevent the team from investing time and energy in the wrong areas.
The feedback you get is yours to resolve
While hearing feedback about the piece of work you’re sharing can be frustrating at times, it is also your responsibility to address it.
“Addressing the feedback” doesn’t necessarily mean “changing your design right away”. Breathe. Here are a couple of things you can try first:
- Having a conversation about the feedback you heard to investigate it and make it actionable;
- Flagging contradictory feedback as a way to force team alignment;
- Identifying key points of feedback that should be addressed versus the ones that don’t (either because they’re not strategically important or because the team is still not feeling confident that they should be addressed immediately);
- Formulating a plan with the team on how the feedback will be addressed, and what the next steps are.
Let’s unpack each of the pain points, and re-frame common complaints in a way where designers take more ownership over the feedback they get.
“Everyone seems to have an opinion about my design”
Could also mean: “everyone I work with is good at what they do”
Getting feedback is the main (only?) purpose of design reviews. Non-designers come to review sessions with the main goal of providing feedback and influencing your designs so it better drives business goals and technical feasibility. Make their lives easier. Instead of trying to avoid feedback at all costs, start with a foundation of trust and be inviting to great feedback.
Also: remember that other people’s comments are always directed to the design, not to the designer. Once you realize that, you might stop taking feedback personally.
“This feedback is too tactical for where we are in the project”
Could also mean: “I should have better set up this review session before I started showing my designs”
Some design reviews have less to do with the specific design decisions you and your team are presenting, and more to do with aligned expectations between what colleagues think they will see and what they actually see in that session. Start the session explaining the type of feedback you are expecting to get, and where you are in the overall project timeline.
“Why am I receiving design feedback from the developer?”
Should become: “I’m glad I’m receiving feedback from the developer early on”
Your design mockup is not the product users will experience. The product (that the developer will build) is the product users will experience. Your main goal as a designer is to get your envisioned design in front of users, and working closely with developers to preserve the original design intention is key to achieve that goal. Embrace that. Design is about getting through the finish line.
“This feedback doesn’t even make sense”
Should become: “I should be asking follow-up questions to clarify what they mean”
I know, not everyone has mastered the practice of giving clear, actionable feedback — and that’s fine. Show people that you heard what they said (even if initially their comment didn’t make a lot of sense), and quickly ask follow-up questions to clarify what they meant. As much as possible, try to tie questions back to project goals and user needs, so that the team can more easily filter out feedback that is merely personal preference: What problem(s) are we trying to solve? What bothers you about X, and how do you think this will affect our users? Why is ‘too much white space’ an issue?
“I wish I’d received this feedback earlier”
Could turn into: “I should be sharing progress more often”
If you’re receiving feedback too late in the game, that might be a sign you are not sharing progress often enough, or that you are not sharing it with the right people. Talk to your project/product manager about how to set a better feedback cadence and avoid surprises later on.
“How am I supposed to address all this feedback by tomorrow?”
Could become: “Let’s prioritize the feedback received”
There will be comments. Lots of comments. No need for despair, though:
- Filter out the comments not everyone agrees with;
- Flag feedback that is contradictory or that goes against the original brief;
- Hold off on the feedback that requires more thought, additional data, or the involvement of additional stakeholders before being fully defined;
- Work with your product manager on prioritizing high vs. low priority comments, and organize the order in which they should be addressed;
- Find ways to “bundle” comments that could be tackled all at once — so you can save time and better plan your next steps.
Receiving feedback isn’t easy, and can often be scary — but relying on and trusting your team is one of the best weapons designers have to ensure their work is getting stronger over time. If you want to be a solid designer, you’ve got to own your feedback.
Recommended reading: Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience
This article is part of Journey: lessons from the amazing path of being a designer.
