Recently, Allison & I (Elle) have been doing a lot of higher impact UX work on docs.mongodb.com and I have found myself in a unique position where my gut just doesn’t like certain designs for no good reason at all. It led me to go down a bit of a rabbit hole around how do I tell Allison this, how do I provide constructive feedback, how do I shape the design to the vision I see for the project without stepping on toes or making a bad call…
So we had a conversation about it — how to provide feedback — and decided that others could benefit from the insights as well. Below we outline the Product Design rationale and the Product Management approach to how we cater to the other. It’s not perfect, but it’s certainly better than “I hate that”.
The Feedback 🧐
1. If you don’t like something…
If you don’t like something, that’s okay! Everyone has their own style, own train of thoughts, own opinions. However, it’s important to assess:
Is this a preference? Or does it have a UX impact?
When you don’t like something, try to identify the root cause. And then express it.
This is important because designers can’t do anything with feedback such as “I don’t like this” or “it’s not my favorite.” There isn’t any reasoning or direction to go off of. Therefore, by expressing the root cause, the momentum of the design process continues.
As mentioned above, if you don’t like something, try to clearly articulate the reason and tie it back to the impact on the users.
However, it’s natural to not like something and it’s also inevitable that sometimes you don’t have a reason for not liking something. When that happens, it’s important to name it but also be open to it. For example (and I do this frequently):
“I don’t love this. I don’t have a good reason as to why and I am happy to be overruled.”
“Could you explain the reason for this component in the design? I’m not sure if I see how how it ties to our business goal of X”
“There is something about this design that doesn’t sit well with me. Is it possible to user test this design against another option to see which resonates the most with users?”
2. If you want something to change…
If you want something to change, again ask yourself why. What’s the reasoning behind it? Make sure to express that so that both design and product are on the same page.
It’s also helpful to have a potential change ready. This provides an actionable improvement that the designer can immediately work off of.
Keeping the conversation open and moving forward is how collaboration continues and ideas begin bouncing off one another.
When requesting a change, try to avoid authoritative language and instead invoke a more collaborative tone like:
“I’d be curious how this looks on the left instead of the right? Right now it feels like the page is off balance.”
“What do you think about removing some of the copy/color to help make the focus a bit clearer?”
Here product management invokes a conversation, not merely requesting an action. Through discussion we can reach a consensus without alienating the other.
3. If you aren’t sure where to say it…
Feedback comes in all shapes and sizes. I categorize feedback into communication methods based on the size of the detail. What works best for us is:
Of course, this took us a bit of time to figure out what works best. Try thinking through questions like:
How does this person react to this type of message? Is it different when I bring it up during a call?
Is this Slack conversation actually getting somewhere? Or are we running in the same circles?
It really takes both parties taking the time to understand how the other communicates. However, if and when you do, I think you’ll find a clearer and more streamlined flow of conversation.
Early on in my career I got the feedback that sometimes when trying to share an idea or thought quickly via Slack it could easily be misinterpreted or misunderstood. This is especially true when trying to provide major feedback about a design. What may feel like a simple “hey I’m not sure this looks how I expected” could in turn be interpreted as “everything is wrong and I am unhappy” when in reality you could be referring to a single component of the larger design or a miscommunication about a goal for the design.
The way to gauge this could be by asking yourself:
“Do I have a lot of feedback about this design?”
“Is it prompting a lot of ideas and thoughts?”
“Is this something that I can’t clearly articulate within a few seconds?”
“Does this require a discussion?”
If your answer to any of these is yes, don’t just leave a comment or send a slack — have a conversation.
4. If you are questioning the design decisions…
If you are questioning the design decisions, always provide a reason. Again, try to communicate your reasoning. As product and user-centric people, bring it back to the user.
Why would my user feel this way? Why would they be bothered like I am?
If you don’t have a good reason or your product designer doesn’t budge, be prepared to let it go. At the end of day, both parties want what’s best for the user.
Trust that the design decision is coming from a reason. Trust that your designer is doing their due diligence in considering the problem, the pain points, the research, and the holistic project space.
It’s worth noting that this is a huge pain point many incoming or current designers face. In fact, this point of tension has created negative phrases such as ‘pixel pushers’ or negative sentiments such as barriers of creativity.
So this is especially important.
It’s never design vs. product or Allison vs. Elle. You are both representing what’s best for your product, your company, and more importantly, your users.
This may sound redundant, but working with design, it’s important to remember that they are an equal — just as engineering is an equal. It doesn’t feel good when every single decision you make is torn apart and it is important to channel that emotion prior to challenging a peers decision. Sure there are times when you believe a little more research here or a little more exploration there could be helpful. Pick your battles, minimize your battles, and make sure they are articulated well, with clear reasoning and the right intentions.
5. If you already have a solution in mind…
If you already have a solution in mind, try waiting to share it until the brainstorming phase of the project. Many times, starting with a solution will close off the problem space and potentially, even fail to address the root cause and create a suboptimal solution.
By waiting to share your idea, you allow the designer to approach the problem with a fresh perspective. By contributing to the brainstorming phase of the project, you’re still able to share your idea, but avoid closing opportunities to new or maybe better ones. It’s also a great place to bounce your idea off others and make it better.
Even when you have a solution in mind, focus on user stories that don’t define the design but rather define the affordance the user has with the feature. This breeds room for new ideas, better ideas than perhaps initial instincts.
User can easily find X based on Y
Users are able to self-service and meet their needs
Users should be able to see context about a given item
Users may see feedback based on their selection
Prior to even defining user stories, include design in the first conversations about the project where it’s not even a fully fledged idea but a signal that this could be a project. Let design help you research and define the problem so that when you move to requirements and they reach the design phase, they are as informed about the project as you are.
Of course these are just a few scenarios that product and design may face but hopefully these examples are helpful for setting the tone for future collaborations. Ultimately, the way one provides feedback is invaluable because it maintains a healthy and productive flow of communication and ultimately, results in a quicker and happier resolution.
If you are new to us, welcome! Read more about our work here.
10 tips to strengthen your Product Design and Product Management relationship
The Product Design (PD) and Product Management (PM) relationship can certainly be a tricky one. Like all high…
If you are new to our blog, welcome! Read more about Product Gals here.