A photograph means different things to different people. That's the point. In a design critique, that same logic becomes the problem.
A street photograph either stops you or it doesn’t.
That’s the whole point. Art is subjective by nature. A photograph that stops one person cold leaves another completely indifferent. Neither response is wrong. The work exists to mean something to someone, even if that someone is only the photographer.
Product design is not a subjective art form.
And the moment a design review starts to feel like one, something has gone wrong.
The room full of feelings
In too many design critiques, a designer shares a screen. Stakeholders respond with feelings. “I don’t like the colour.” “Something feels off.” “In my opinion the button should be bigger.” These are reactions, and when enough of them pile into a room together, you end up with the bike shed.
Bikeshedding comes from Parkinson’s Law of Triviality. The principle is blunt: the less technical complexity a topic requires to have an opinion on, the more opinions it attracts. Nobody argues about the underlying architecture. Everyone argues about the colour of the button. The actual UX problem, the one that will cost real users real time, sits quietly in the corner while the room debates font weight.
The deeper issue runs underneath this. Stakeholders often confuse two things that are completely different: being a user and being a user expert.
Sometimes a stakeholder genuinely is the persona. They use the product daily, they hit the friction, they know exactly where the flow breaks. That perspective is valuable because it’s lived experience of an actual problem. Those stakeholders are useful precisely when they stop saying “I don’t like it” and start saying “I get stuck here every time.”
But most stakeholders are not the persona. They’re removed from the daily reality of the people the product was built for. When they respond emotionally to a design, they’re not giving you user insight. They’re giving you personal taste. And personal taste, however confidently delivered, is not a design constraint.
The question that separates signal from noise in a design review is simple: does this solve the problem the user actually has? If the answer requires data, research, or reference to a defined persona, you’re in the right territory. If the answer is a feeling, you’re not.
What photography gets right
A photograph is judged by whether it communicates. The quality of light, the subject’s relationship to the frame, the moment chosen over the hundred moments rejected: these are craft decisions made in service of a specific intent. You can discuss whether they worked. You cannot simply say “I don’t like it” and expect that to land as useful feedback.
The same standard should apply to a design review.
A design decision should be evaluated against the problem it was built to solve, the user it was built for, and the constraints it was made within. Someone’s aesthetic preference, formed in the forty seconds they’ve been looking at the screen, doesn’t come into it.
“I don’t like it” is a complete sentence in a gallery. In a design critique, it’s an incomplete thought.
What good looks like
Good design critiques are grounded before they start: the persona, the problem, the constraint. Feedback lives inside those parameters or it doesn’t get through the door.
They also separate problems from solutions. “The navigation feels unclear to me as someone who doesn’t know this product” is a problem observation. “Move the menu to the top left” is a solution delivered by someone who hasn’t done the work to earn that call. One of those is useful. The other is a solution dressed as feedback.
Jakob Nielsen has catalogued thirteen distinct ways design critiques fail. Most share the same root: feedback untethered from the problem. Different names for the same failure mode, whether it’s the highest-paid person’s opinion dominating the room, vague directions nobody can act on, or debate about trivial details while real UX issues go unaddressed. In each case, the room is treating the design as art, responding to it emotionally and judging it by feel.
A structured UX process makes this unnecessary. When the research is done, the problem is defined, and the persona is grounded in data, “I don’t like it” has nowhere to land. The design is either solving the right problem or it isn’t. That’s a question with an answer.
The same word, two different worlds
In photography, subjectivity is the whole conversation. In product design, it’s the conversation that ends the real one.
The goal of good design is a product that works for the people who have the problem it was built to solve. Stakeholder approval is a business process. User outcomes are the actual brief.
The quieter the room gets about personal taste, the louder the work becomes.
If your team is caught in review cycles that generate opinions instead of decisions, that’s a process problem before it’s a design problem. Let’s talk.