With over 12 years of experience as a UX designer needing to craft relationships with developers and now leading design and development teams, I’ve seen my fair share of drama between design and development teams over the years. In this drama, both teams can play the villain’s role.

Why Does Conflict Arise?

Past Trauma

Many teams are impacted by past toxic environments. Unfortunately, these historical patterns do play a big role in the designer-developer relationship.

I still remember a design-and-dev-sync meeting at my first UX job in which a senior designer demanded the details of how the design we had just discussed would be coded. As the junior developer struggled to respond immediately, the senior designer condescendingly suggested multiple solutions that he thought were “right.” I cringed.

In hindsight, while I still think he was wrong, I wonder if his behavior stemmed from a poor previous experience. If, in the past, the senior designer had been burned by lazy builds that made him look unprofessional, then no wonder he was motivated to take matters into his own hands.

Power Dynamics

Power dynamics also add to the tension between the design and development teams. A lot of times, it comes down to who has the final say on something. For example, design won’t sign off on developers’ implementation because multiple large design changes were added at the last minute and the project deadline did not adjust for those changes, or because the implementation doesn’t meet a level of polish that was not discussed or agreed upon before. 

In the same way, development might decide that a seemingly simple design will require a million development cycles to complete, ultimately forcing the design team to change the design to get it implemented.

Low Team Maturity

When a lot of finger-pointing is happening and no one is taking rightful responsibility, trust among the team diminishes, and members on either team are unwilling to speak up and collaborate positively. For example, developers may not feel safe enough to give feedback during design reviews, but then they may complain about the design scope and complexity during the build phase.

Poor Processes

Involving the development team late in the design process often leads to team friction and rework, slowing progress. If developers see the design only after user testing and stakeholder validation, it’s already too late.

Owner of Design, Owner of Code, Coowners of the Outcome

Each team handles distinct responsibilities. The design team focuses on optimizing product usability. The development team manages the implementation of the product and is responsible for identifying technical and usability constraints. Both teams are necessary to achieve positive product outcomes and share the goal of improving the final product and its user experience.

Instead of fighting with each other, the design and development teams should approach collaboration as coowners of the product experience. This mindset shift helps emphasize collaboration, allowing team members to work together towards a shared objective instead of seeing themselves as adversaries.

Tips for Making Coownership Work

Besides remembering that you’re on the same team and that your process should foster a positive working environment and relationship, here are a few tips for making coownership work.

Build a relationship with one person on the “other” team. Partner up with one other person and grow trust with one another. For example, if you’re a designer, reach out to one developer and ask them for their opinions on design or dev-related matters outside of meetings to get to know them. Once you feel like you’re in a solid place, start to build a relationship with someone else on the dev team. Having key people on the “other” team will facilitate productive conversations about tradeoffs and boost confidence in what they have to say.

Communicate to understand, not convince or prove. This is vital for anyone trying to collaborate in a healthy way. It includes being open to hearing what the other person is saying. Often, you may feel like you are overcommunicating in an effort to understand. For example, you may need to repeat back what others are saying to show you are listening: “What I hear you saying is that…xyz” or “I want to make sure I understand what you’re saying…do you mean xyz?” 

Establish a shared vocabulary early. Developers and designers often use different terms for similar concepts — for instance, “breakpoints” versus “responsive design.” Agreeing on language improves mutual understanding.

Simplify the explanation and skip the jargon. Designers and developers use their own specialized jargon that can be confusing. By simplifying your explanation and focusing on key points, you help others understand quickly without feeling lost or dumb. This approach is especially useful for technical issues.

Acknowledge invisible work. Invisible work refers to tasks that are often unnoticed or uncredited, such as recognizing added development complexity from minor design changes or keeping the backlog organized. It can be as simple as saying thank you for their effort. While acknowledging this work supports collaboration, avoid overdoing it so it does not come across as insincere.

Don’t take feedback and changes personally. Design is in the details. Even minor tweaks can have a big impact on usability. Expect frequent changes and be open to giving and receiving feedback, knowing that it’s ultimately in service of the best possible end-user experience.

Coownership Benefits

Treating design and development as joint contributors to the product experience has ample benefits.

Trust among team members. Sharing a common goal builds trust between designers and developers. For instance, designers will be more likely to accept when developers say coding certain features will take a long time because they trust them.

This increased trust encourages teams to make tradeoffs and be flexible with one another. When a designer recognizes that their development counterpart is earnestly seeking the best solution, they’ll be more receptive to alternative development suggestions and more inclined to collaborate. Similarly, a developer may be more willing to accommodate unplanned tasks due to the positive relationships established with the designers. 

Higher velocity. Greater trust between design and development teams boosts momentum. Designers can work faster because they would have listened to development feedback on their early designs, causing fewer coding roadblocks. Because there are fewer coding roadblocks, the design gets implemented more efficiently. It’s a win-win.