When a developer thinks they’re the designer, and how to work it out together

Two people, two problems

When I look closely at these situations, the developer is rarely being careless or arrogant. They are solving a different problem from the one the designer solved. The designer was thinking about the user’s path through the task; the developer was thinking about performance, data that arrives late or a component that would take a week to build as drawn. Both are legitimate concerns. The trouble is that nobody put them on the table together.

Agree on the problem first

So the first conversation is never about who was right. It is about what the screen needs to achieve and what constraints it has to respect, from both sides. Once those are written down, the design argument usually dissolves on its own. Sometimes the developer’s change was better and we keep it. Sometimes a small adjustment satisfies both the user’s need and the technical limit. Occasionally the original design stands, and now everyone understands why.

Bring developers in earlier

The lasting fix is to stop meeting at the end. On my team, developers see designs while they are still rough, and designers hear about technical limits before they polish anything. A short conversation at that stage saves days of rework later and removes the feeling that design is something handed down rather than built together.

Respect in both directions

Developers who care about the interface are an asset, not a threat. Their instincts are often good, and their knowledge of how things actually behave makes the design better. What they need is a clear process for raising ideas and a clear owner for the final decision. What designers need is the humility to listen. With both in place, the question of who the designer is simply stops coming up.