How to Give Feedback to Engineers Without Damaging the Relationship

Giving feedback to engineers is one of the more delicate things designers do, and it goes wrong in predictable ways.

Either the designer is too vague ("this doesn't feel quite right") and the engineer doesn't know what to change. Or the designer is too prescriptive ("move this 4px to the left") and the engineer feels like they're being micromanaged. Or the feedback comes at the wrong stage, after the engineer has already shipped, and the conversation turns defensive.

Getting this right matters. Your relationship with engineers affects how your work gets built and whether people want to work with you again.

Understand what "done" means to them

Engineers build to a spec. Their definition of done is usually "it matches what I was given." When you give feedback after implementation, you're asking them to reopen something they considered closed.

That's not a reason to avoid feedback. It's a reason to give feedback earlier, when the cost of changing something is lower. The more you can push your design review to happen before implementation rather than after it, the easier your feedback conversations will be.

When you do need to give post-implementation feedback, acknowledge that this is reopening closed work. A small acknowledgment goes a long way: "I know this is late, and I appreciate you taking a look at this."

Be specific about what's wrong, not what to do instead

The most common mistake: telling an engineer what the solution is rather than what the problem is.

"Can you add more padding around the text" is a solution. "The text feels cramped in this layout, especially at the smaller viewport sizes" is a problem statement. The second framing gives the engineer room to solve it in a way that works technically, and it shows you respect their expertise.

Engineers are good at their jobs. They often know faster than you do how to fix something once they understand what's wrong with it.

Separate "must fix" from "nice to fix"

Every piece of feedback should come with an implicit or explicit priority signal. If everything is equally important, the engineer has to triage it themselves and will inevitably deprioritise things that matter to you.

Make it easy for them: "This spacing issue is blocking, it significantly affects usability. This one is a minor visual thing we could address in a later pass." That clarity is a gift. It also signals that you understand constraints and aren't just generating work.

Ask questions before stating problems

Sometimes what looks like an implementation problem is actually the right call given a constraint you didn't know about. Before saying "this doesn't match the design," try "help me understand how this is working, was there a reason we went this direction?"

You'll occasionally find that the engineer's version is better, or that the original design wasn't feasible, or that something else is going on that context changes your feedback entirely. Going in curious instead of corrective saves you from giving feedback that turns out to be wrong.

Build the relationship before you need it for feedback

The best engineering relationships are built long before any specific feedback conversation. They're built in planning, in design reviews, in casual conversations about what's hard to build and what isn't.

When an engineer understands how you think and why design quality matters to you, your feedback lands in a different context. It's coming from someone they trust and whose judgment they've seen in action, not a stranger with a red pen.

Invest in those relationships consistently. Show genuine interest in what engineers are dealing with, not just when you need something from them.

Your tone is more important than your words

The same feedback delivered with warmth and curiosity lands completely differently than the same feedback delivered with frustration or superiority.

Designers sometimes forget they're not the only expert in the room. Engineers have knowledge and judgment that you don't. Approaching the conversation that way, as a collaboration between two people with complementary expertise, makes almost every feedback interaction go better.

If you're frustrated about something, figure out why before you say anything. Usually the frustration is about process (seeing this too late, not having the right conversation earlier) rather than the engineer themselves. Address the process, not the person.