There's a version of the job designers don't talk about much: you've been asked to execute a direction you know isn't the best one. Maybe it came from a stakeholder. Maybe the right approach was deprioritized for speed. Maybe you pushed for something better and didn't win.
Now you have to stand in the room and present it.
This happens more than people admit. And how you handle it matters — for your credibility, for the team, and for the product.
First: be honest with yourself about why
There's a difference between "I don't believe in this because it's wrong" and "I don't believe in this because it wasn't my idea" or "because I'd have done it differently."
The first is a signal worth acting on. The second two are professional friction that's mostly yours to manage.
Before doing anything else, be clear which situation you're in. If the design has a genuine problem — a usability issue, an inconsistency with established patterns, something that will predictably confuse users — that's different from "I would have made a different call." Both deserve a response, but not the same one.
If the concern is real, surface it before the room
The worst time to raise a concern about a design is during the presentation of it. If you present something and then immediately caveat it, you've undermined both the work and the process. Everyone in the room is now wondering why they're looking at something the designer doesn't stand behind.
If you have a real concern, raise it one-to-one with the PM or design lead before the broader review. Be specific: "I'm worried about X because of Y. I wanted to flag it before we present." You might not change the outcome, but you've documented your thinking, given the decision-maker a chance to respond, and kept your integrity without derailing the room.
In the presentation itself
Once you're in it, present properly.
Don't hedge publicly. Don't say "I'm not totally sure about this" or "this was kind of a compromise." If the design is being presented, it's being presented as the current best answer. Treating it as a placeholder in front of stakeholders introduces doubt that doesn't serve anyone.
You can — and should — be accurate about what the design solves and what it doesn't. "This addresses X and Y. We've scoped out Z for now because of timeline" is honest without being undermining. It names limitations without apologizing for the work.
What to do after
If you genuinely believe the design is wrong, the right move is to keep a record of your concern and revisit it when there's evidence. "I flagged this before launch, and here's what we're seeing now" is a productive conversation. It shows you were paying attention, not just venting.
If you were wrong — if the design shipped and it worked fine — update your priors. Sometimes the direction you didn't believe in turns out to be good, and your skepticism was based on incomplete information. That's worth knowing about yourself.
The longer game
Designers who present every design with the same conviction, regardless of whether it was their idea, are more trusted over time. Not because they're uncritical, but because their credibility isn't tied to proving they were right in any particular case.
Raise concerns clearly. Execute well. Update based on evidence. That reputation compounds in a way that being right about any one design never does.
Credits & further reading
- Articulating Design Decisions — Tom Greever (O'Reilly). The underlying principle in this note — that how you communicate your work is inseparable from the work itself — is the central argument of his book. His advice on navigating disagreement with stakeholders without losing your credibility is directly relevant here.
- Radical Candor — Kim Scott. The "care personally, challenge directly" framing is useful for the moment where you have a genuine concern about a design but need to surface it without derailing the team. The distinction between "this is my opinion" and "this is a problem for users" maps roughly to her distinction between ruinous empathy and radical candor.
- The Courage to Be Disliked — Ichiro Kishimi & Fumitake Koga. Tangentially relevant but worth reading if the "hold your ground" piece is something you find difficult. The Adlerian framework it presents separates your task (raising a concern clearly) from someone else's task (deciding what to do about it). That boundary is worth internalizing.