Designer/Developer Dissonance: How to Create Harmony for Your Next Project

User experience (UX) designers and developers are different types of thinkers and approach the same problems from different vantage points. That can be a good thing if designers and developers can find synergy as they solve problems for users.

Fortunately, over the past few decades both groups have become radically better attuned to the user. The awareness, knowledge, and research of users has increased steadily since the mid-century birth of the modern computer. Today, both designers and developers take humans more seriously in the equation of human/machine interaction.

Still, there’s often disconnect between designers and developers. That’s due in part because they represent different interests in the final product. The designer is responsible for the user’s satisfaction and the developer is responsible for the viability of the technology.

But, more fundamental today is the fact that designers — and I’m making a broad generalization about the profession — have become more specialized and less technical.

Even 30 years ago it was nearly impossible to be an interface designer and be taken seriously if you weren’t also a programmer. You essentially did everything in an interface, from user research to development. Today, the UX design profession is expansive, with practitioners often specializing in just a fragment or two of the process.

That’s why “designer” can be a vague term. We have user researchers, information architects, interaction designers, visual designers, and so on. That means more opportunities for the priorities of individuals to come into conflict with one another across the divide of development and user experience.

For a project to reach its goals and for the team to produce quality products on budget, effective collaboration between the two camps is essential. Following these three steps wil help you achieve it:

1. Align each team’s mission on the project with the mission of the product itself

This removes the “I” from the discussion. “I think we need a wizard here” or “I think we must have search” goes away. Instead focus is brought back to the requirements and constraints of the product itself, including the limitations of budget and technology. Personal likes and prejudices are put aside for the greater goals of the project itself, which usually leads directly to greater product success. And that’s what you want.

Keeping your eyes on the prize (final product) creates better alignment of goals in the competing priorities of users and technology. Remind your team of the product mission frequently and how your team’s mission fits with that.

2. Communicate with each other, as in old-fashioned talking

Software products consist of tons of details, each that need to be designed and built by human hands, so to speak. A UX design specification (specs, mockups and prototypes) contains much information for developers to work from but it is often prohibitively expensive to create design specifications that cover every detail, in detail. That means design specs realistically only answer some of the questions of what a product is, and many questions remain. A product design is also a collaborative effort between designers and developers, so discussion is needed just to get to a so called “final” design.

There is little doubt in my mind, and I speak from experience, that rich, ongoing dialog between developers and designers during a project is extremely beneficial to successful outcomes.

3. Expect iteration and plan for progressive completion

The problem of not being able to create complete and perfect design specifications has actually been solved — and it’s actually better than having perfect specifications. The solution applies a process to the design and development of software that is more akin to how the creative process works in general. I’m talking about trial and error — working your way through progressive iterations to a good outcome. In other words, agile development (and related methodologies such as Lean).

Agile-like methodologies essentially enable the completion of simplified versions of a product (MVP or minimum viable product) or elements of a product, as part of the overall production process. It takes a large problem (a whole product) and breaks it into a bunch of little problems that can be solved progressively.

It is a much more natural and effective way to create something of high quality than separating design and build into two discrete phases. You don’t have to presuppose every detail. It allows problematic issues to be revealed and addressed early. And it requires an ongoing back and forth between design and development, which insures that communication happens.

With agile-like methodologies, risk is reduced and creativity is increased. Communication also tends to increase inherently, because of the nature of having progressive, short-term goals or “sprints.”

The takeaway: UX designers and computer developers are inherently at odds with each other because they each serve a different master, and that is necessary. But, by following these three common-sense recommendations, the process of collaboration can be highly creative and fruitful, and likely less contentious.

To read more about design leadership, visit our UX blog.