Where Design and Engineering Collide

Conflicts between UX designers and software engineers are rarely about personalities. They usually stem from structural pressures, misaligned incentives, or simple timing issues that snowball into “us vs. them” standoffs. Designers hold the keys to customer need and the principles of a delightful experience; engineers hold the keys to feasibility and how the technology actually works. The outcome is best when both sides contribute — but reaching that point requires understanding where the friction comes from.

In my experience, engineers often have an easier time grasping what makes a good user experience than designers have understanding the technical constraints of a solution. That asymmetry can frustrate both parties. But the conflicts are not inevitable cultural phenomena. They are products of specific conditions — some tied to how teams are structured, some to how success is measured, and some to timing and communication habits.

The Fault Lines

Looking at where these conflicts originate, a few recurring categories emerge: culture, teams, roles, and individuals. As research notes, the structure of the organization itself can directly contribute to conflict, particularly regarding how authority is distributed.

Culture

Teams do what they are rewarded for. When incentives emphasize output over outcomes, teams become efficient at shipping features — even features that fall short of customer expectations. The result is a “good enough” culture that consistently misses the mark once a product reaches real users.

Teams

Team sub-cultures often twist broader company values. A collaborative corporate culture can still contain teams that become hyper-focused on productivity metrics, using those numbers as a shield against uncertainty. In one such case, sizing a single user story consumed nearly an entire meeting because the team’s focus had narrowed so far inward.

Roles

Strictly staying in one’s lane is counterproductive. Engineers should have opinions on design; designers should have opinions on the technical approach. The cross-pollination of views almost always yields better results than isolation, even when it feels uncomfortable.

Individuals

Each of us can be either a contributor or a hindrance. When personal focus overtakes team focus, voices get forced rather than shared. That’s when engineers respond with “just tell me what you want from me” — a sure sign that collaborative intent has been replaced by transactional instructions.

Conflict in Practice

I have seen these dynamics play out in concrete ways. In one company, an entrenched engineering culture had created a clear split: “let us build it, get out of the way, and we’ll let you know what we need.” When I attempted to facilitate a brainstorming session with sketching exercises, the response was blank stares followed by a stream of technical constraints. Looking back, the root cause was not engineering resistance — it was a lack of product owner buy-in and proper context for the session. Without that groundwork, the session only reinforced the existing divide.

At another company, the problem sat with middle management. Senior leadership promoted collaboration, design quality, and high-quality outcomes. Agile teams believed in that vision and worked toward it. Middle managers, however, made decisions that ran completely counter to leadership’s direction. An engineering manager instructed engineers to build without including design or product management. When designers tried to participate, engineers explained they were simply following orders — and the product showed it.

These situations call for patience. Sometimes the dysfunction is cultural, but sometimes it is just the product of people being caught in the middle of conflicting directives. If teams genuinely want positive change, they usually find a way around these walls.

Schisms, Conflicts, Distractions

Studies consistently find that the most common type of conflict between designers and engineers is task-based. A 2002 study reached that conclusion, as did a 2019 study where 100% of reported conflicts fell into this category. From my experience on the ground, most of these barriers are not real cultural adversaries at all — they are distractions that obscure the shared goal.

Timing

Designers tend to build ideas up inductively; engineers break them down deductively to plan construction. Both modes are necessary, but they need to happen at the right moments. A recurring source of conflict is trying to brainstorm while an engineer is trying to decompose the work into buildable chunks — mismatch guaranteed.

Miscommunication

Designers and engineers have different backgrounds and vocabularies. As Ari Joury points out, that difference alone brings frustration. The same word can mean different things, and technical terminology is not always transparent to non-engineers.

Misalignment

Without a shared frame of reference, disagreements will emerge. Not everyone can see every detail in real time, but the team needs a common understanding of what problem is being solved and why. When that understanding drifts, team members start pulling in different directions.

Role Factions

Arguments about who owns which part of the solution are generally signs of a deeper collaboration deficit. In a healthy environment, the team owns the solution collectively. Designers should be willing to step into engineering discussions; engineers should treat design as part of their domain to learn, not inspect from a distance.

Metrics

Metrics can focus teams on outcomes, which is useful. But the balance is delicate. Metrics on value delivery versus metrics on team productivity often pull against each other. When a team becomes obsessed with optimization, it burns energy chasing details instead of making progress. As Churchill observed, perfection is the enemy of progress.

None of these factors are insurmountable on their own, but several can compound. The reality is that designers and engineers will face conflict whenever they work together. The best teams accept that reality — and make it a point to lean in instead of pulling apart.

Building Team Unity Starts With Trust

Trust is the foundation that makes cross-functional collaboration work. When it is missing, designers and engineers tend to question each other’s motivations and abilities. As Jillian Priese, Engineering Manager at Granular, told Built In in 2021, “When trust is present, it makes all the difference in the world.” Teams need deliberate strategies to close the gaps that keep disciplines apart, and practical tactics do exist that can make a real difference.

  • Discover together. Bring engineers into the discovery phase. They benefit from observing user research on the code they build, and they should participate in ideation, helping to shape proposals toward more feasible, higher-value outcomes.
  • Stay curious. Avoid assumptions on both sides. Cross-pollination of skills strengthens teams. Spend time understanding what your counterpart does, and keep each other honest through empathy.
  • Find a common vocabulary. Designers and engineers often assume they mean the same thing, only to later realize their words map to different concepts. Engineers should translate technical constraints patiently; designers should reach for sketches and visuals to communicate intent.
  • Sit next to each other. Physical proximity builds understanding. Learning about individual engineers’ work, their workflows, and their constraints informs better design. For remote teams, that means making a shared commitment to availability and reliability.

When engineers are genuinely aligned with UX designers, they elevate already-good designs into great ones — they are the ones who breathe life into a user experience through technology.

Applying These Ideas In Practice

Every organization is different, so the team’s specific context should dictate which approaches work best. The following are examples of how these principles can be applied on real-world projects.

When You Are The Outsider

In one role, a lone designer was placed into a technical, engineering-focused team in another country. Progress was slow until she petitioned to work on-site for several days. There she focused on an epic with heavy frontend work and ran some design exercises the team had never tried. A lateral thinking exercise and a UI pattern workshop broke the ice. The team became more sensitive to user needs and began proactively reporting UI issues and proposing solutions. A base of openness had already existed, and structured time together drew it out.

Bring UX To Where Engineering Lives

Another organization housed UX within Product Management, on a different floor from Engineering. Despite proximity, or physical distance, the departments stayed siloed. The designer started setting up a “UX Help Deck” in the engineering area several times a week. What seemed odd at first turned into a channel for learning about the team’s technical stack and constraints, for aligning on user needs, and for connecting with product owners and engineering managers. Those in the engineering team valued the presence highly, which accelerated progress on building good relationships.

Translating UX Into Scalable Architecture

At a much larger company, the engineering culture was heavily entrenched, and its architects had little experience working with UX. Architects would cite obscure edge cases during discussions, treating them as a trump card against user-centered recommendations. UX was understood as making things “look pretty.” The in-road came by reframing design in their terms: system robustness, scalability, and maintainability.

The team urgently built a design system to act as a frontend foundation and used it as the base for structured guidelines in engineering. Within those modular, scalable constraints, designers still focused on user needs. The architects came to see UX design as a partner supporting the systemic goals of the team rather than a competing interest. The design system was instrumental — engineers quickly bought in, and traction with the architects followed slowly.

Leave Room To Do Things Differently

Finding the barriers against unified teams is central to the work. It takes effort, will require experimentation, and assumes a degree of patience. The same intervention will not necessarily apply across groups, and when there is resistance, treat it as a signal to lean in rather than away.

Keep these targets in mind when looking for the root of disagreement:

  • Where are the biggest gaps between roles, and what level of the organization do they sit at?
  • What distracts each group from making the other’s needs transparent?
  • Where can you take action to create one reasonable next step together?

Sometimes, building unity requires challenging the very status quo you want to change. It may ruffle feathers early, but disruption can be the path to a better state — and what starts as resistance often evolves into respect. It can feel like only thirty percent of your peers are fully behind the change, with another thirty percent curious but unconvinced. Yet as the rest of the team unites around a new way of working, even the loudest minority of naysayers will eventually be looped back in. Persistence and genuine collaboration will hold the group together.