How Designers and Developers Can Learn to Like Each Other

Joshua Kraus
Joshua Kraus

History is filled with legendary rivalries. Ali vs. Frazier. Tesla vs. Edison. Coyote vs. Road Runner.

But the rift between designer and developer eclipses them all. While both disciplines are necessary to create an effective application, the working relationship is often an uneasy one, fraught with conflict and misunderstanding.

Designers, for example, are miffed when they feel the developer isn’t honoring their vision. Developers, on the other hand, are irritated when the designer delivers an unworkable model. Designers can seem overly nitpicky, while developers can come across as small minded.

The Root Of The Problem

The designer/developer schism is rooted in each party’s misunderstanding of the other’s mindset and discipline.

A designer is tasked with envisioning how something will look, feel, and behave, but they’re not responsible for executing that vision. Thus, their design might be unfeasible or impractical.

A developer must translate a designer’s vision into a working product, even if that means altering, trimming or rejecting part of that vision due to technical constraints.

This can be frustrating for the developer, especially if they mistake a designer’s unrealistic demands as a sign of disrespect to the developer’s craft.

When all these wires get crossed, the relationship suffers, and so does the end product. But designers and developers are not fated to butt heads forever. Here is how the two can cultivate stronger, more productive relationships.

Empathize With Each Other

Ah empathy, sympathy’s more exhausting cousin.

To empathize with another person is to see the world through their eyes. And no, it doesn’t require invasive surgery.

A designer should try to empathize with a developer’s technical capabilities and limitations. Developers can create some pretty marvelous things, but they’re not gods. A website that simulates what it’s like to ride a dragon through the Horsehead Nebula might sound wonderful, but the technical demands of such a project may be a smidge too high.

Designers also need to empathize with a developer’s unique working situation. While a developer may have the technical prowess to build something, factors such as time and budget can put a stop to their plans.

Meanwhile, a developer must empathize with a designer’s priorities. Web designers aren’t artists so much as they are problem solvers, and if they’re being too nitpicky or too fanciful, it’s not for the sake of preserving their artistic integrity; it’s because they believe the developer’s changes or rejections will negatively affect the end product.

It’s important to remember that it’s a designer’s job to be nitpicky. There is a rainbow of difference between purple and blue violet; an ocean between 40px and 44px.

Good designers are detail-oriented by nature. Their goal isn’t to give developers a hard time, it’s to create the best product.

Understand The Basics Of Each Other’s Discipline

Empathizing with one another is a great start, but the best designer/developer relationships are forged when each party understands the basics of the other’s discipline.

A good designer should be familiar with the capabilities and limitations of web development essentials, such as JavaScript, HTML and CSS.

For example, to a designer with very little development knowledge, changing a drop down box to multi-select check boxes might not seem like such a big deal, but to a developer, it might shake the project’s very foundation.

A designer who understands basic web development principles will also know that:

  • It’s rarely necessary to design things in 300dpi. Stick with the web-friendly 72dpi unless told otherwise.
  • Including five different fonts in a design might look great, but most web fonts cost money and have large file sizes. Default to standard fonts when possible.
  • Using 20px for the margin-top in one spot, then switching to 25px somewhere else can severely complicate the development side of things. Same goes for different font sizes and colors.
  • Things that are easy in Photoshop such as type on a path are not well-suited to browsers.

But the road goes both ways. A good developer should familiarize themselves with design basics such as color theory, alignment and navigation models.

Understanding how each aspect of a design contributes to the overarching goal of the site can give developers a greater appreciation for the smaller details they would have otherwise dismissed. Aesthetic choices which can appear arbitrary may actually serve an important purpose. Something that seems like mere decoration may actually be a crucial design element.

Communicate Better

Miscommunication is the well from which so many problems spring. While empathy and understanding are a necessary first step, engaging in accurate and meaningful communication is paramount to a successful relationship. By the way, bookmark this article if you ever need marriage advice.

Good communication is about honesty and education. Rather than stew silently at their respective desks, designers and developers need to clearly and respectfully explain why something can’t be done, or why that something absolutely needs doing. Only then can they begin to resolve the issue.

For example, a developer may start fuming after receiving multiple designs that are technically unfeasible, but if that developer doesn’t communicate to the designer the exact nature of the problem, those fumes will reach hazardous levels.

A designer may propose a feature they know is difficult to implement, but rather than drop it in the developer’s lap and walk away, perhaps the designer wants to work with the developer to solve the problem together. If the designer doesn’t communicate this to the developer right away, the developer is going to assume the worst.

Developers should also consider defining the technical requirements of the project as early as possible. This way, the designer is aware of factors like resolution and screen size, site architecture and application flow, which can cut down on potential problems down the road.

Ongoing Collaboration

If the designer hands over their work and skips town, that’s not a relationship, it’s an assembly line.

Rather than remain completely independent from each other, designers and developers should engage in ongoing collaboration. Questions will arise, errors will accumulate and ideas will evolve. Talking through new developments ensures that each party is on the same page, and that the solution will be attacked from all angles.

Ongoing collaboration also pushes each party to their fullest potential. You may not always agree, but a little conflict challenges everyone involved to work harder, aim higher and think more critically.


By setting aside egos and walking a day in the other’s shoes, designers and developers can build the trust, rapport and respect necessary for any relationship to thrive. Talk through issues rather than assume the other is incompetent. Learn the basics of each other’s discipline in order to plan ahead and ask the right questions.

Designers and developers, with your powers combined, simulating what it’s like to ride a dragon through the Horsehead Nebula may just become a reality. And no, of course I didn’t write this article solely in the hope of inspiring someone to create said simulation. That would be ridiculous.