Product Design
The Weight of Opinion in Design
Every product has its loudest voices, but volume isn't the same as insight. Good design leadership means creating space for different perspectives while staying grounded in the users, evidence, and problems that brought the team there in the first place.
There’s a particular kind of design feedback that can be difficult to navigate. You’ve explored the problem, considered different directions, gathered feedback, and perhaps even tested the experience with users. Nothing is pointing to a significant issue, yet someone internally looks at the work and says, “I don’t think this is right.”
That moment can create an unexpected amount of pressure. A design decision that felt grounded in evidence suddenly becomes something you need to defend. After years working across Product Design and Product Management, I’ve learned that internal feedback is valuable, but not all feedback carries the same weight.
Listen, but Understand the Signal
People bring their own experiences, preferences, expectations, and history with a product into every discussion. A stakeholder may prefer the familiar experience. An engineer may see a technical risk. A product leader may have a different business concern. A designer may simply have another perspective. All of those opinions are worth hearing, but hearing them doesn't mean they should automatically change the product.
The important distinction is between feedback that reveals a problem and feedback that expresses a preference. If one person struggles with a design, that can be a useful signal to investigate. If research, testing, analytics, and customer feedback consistently point in another direction, that is also a signal. The goal isn't to ignore the internal voice, but to understand what it is actually telling us.
Don't Design by Committee
As more people get involved in a product, everyone naturally develops an opinion about the experience. If every opinion becomes a requirement, the product slowly turns into a collection of compromises. One person changes the navigation, another changes the interaction, someone else changes the hierarchy, and eventually the original rationale disappears. What started as collaboration becomes design by committee, where the strongest voice in the room can have more influence than the evidence.
That doesn't mean evidence should become a shield either. When someone challenges a design, I want to understand what they are seeing that I might not. Are they identifying a business constraint, a technical limitation, an accessibility concern, or something our research didn't cover? Sometimes disagreement reveals a blind spot. Sometimes it reveals nothing more than personal preference. The job is to find out which one it is.
Make Disagreement Useful
One of the most useful things we can do is turn disagreement into a hypothesis. Instead of debating whether a design is good or bad, ask what specifically isn't working and why. What makes you think users will struggle with this? What problem did the previous experience solve better? What user need do you think we're missing? Those questions move the conversation away from personal taste and toward something that can potentially be tested.
And sometimes, after listening and evaluating the concern, the right decision is simply not to change the design. That's part of being a senior designer or product manager. We can acknowledge the concern, explain the trade-offs, and move forward when the evidence doesn't justify changing direction. If new information proves us wrong later, we adapt. The important thing is that the product changes because we learned something, not because someone won an argument.
Organizations will always have strong personalities and influential voices. That's inevitable. What shouldn't be inevitable is allowing those voices to define the product by default.
The goal isn't to design for the loudest voice in the room. It's to design for the problem we're actually trying to solve.
Back
