Though they share the same goal, developers and designers have different, even opposing, motivations. Both sides could learn a tremendous amount from each other, yet layers of resistance persist. One of the main reasons for this resistance is the unfamiliarity with each other’s expertise, which can create misunderstandings and lead to project conflicts.

So how can these two roles bridge the gap to cooperate better on crafting the final winning product?

We — Max Kozinenko and Leonard Reese — have written this article to share with you our combined personal experiences collaborating on application development teams. Both consultants in SoftServe’s Center of Excellence stationed in our Singapore headquarters, we originally developed this content as a live lecture co-sponsored by General Assembly for its Design Week in Asia-Pacific.

Once upon a time…

/uploads/stories/developer-vs-designer-dot-finding-the-common-ground/panel-1.jpg?1651166227037

To better understand the nature of these conflicts, let’s first recount an all-too-familiar story. Once upon a time, a client approached a development team with an ambitious concept for an exciting new technology product (let’s think of the product as a “horse” for the sake of this metaphor). The designer on the team thought long and hard about how to impress the client, and he disappeared into the studio to craft the designs under lock and key. When he emerged, he unveiled the most amazing mockups the client had ever seen! The presentation was a huge success, and the designer went along his way.

/uploads/stories/developer-vs-designer-dot-finding-the-common-ground/panel-2.jpg?1651166356998

The design specifications were then “pitched over the fence” for the engineering team to provide estimates on how much time and effort would be required to develop the application. Seeing the mockups, the engineers were horrified at the implied functionality! The designs didn’t seem to consider any existing technology frameworks and would have to be completely custom developed. The client was not happy but agreed to the engineers’ heavy redesign suggestions to conserve budget.

/uploads/stories/developer-vs-designer-dot-finding-the-common-ground/panel-3.jpg?1651166522149

The product requirements were processed into a backlog of user stories, and the project entered the implementation phase. The developers toiled tirelessly for months processing the user story tickets, doing their best to interpret the specifications. At long last, with the final ticket implemented, the developers pitched the completed application back over the fence for final inspection before launching to users. The dismayed designer cursed the developers for mangling his designs into such a pitiful distortion of the original vision. In the end, the real losers were the users—product adoption was dismal, and the project lost all momentum.

So, what went wrong?

Who’s to blame for the project failure? On one hand, the designer certainly had uninformed expectations of what could be developed; but on the other hand, the developers didn’t help the situation by trying to fix all the design problems themselves without asking for help.

The truth of the matter is that this story was a tragedy of poor product development. By following this rigid, linear process the product was doomed to fail from the beginning. This is what’s often pejoratively referred to as “waterfall” development, flowing downstream from phase to phase towards product launch.

Motivators

As members of the development team (yes, designers, we’re including you too), you can influence this culture of product development. To improve your ability to collaborate with your counterparts, consider what motivates them in their work.

Developers’ motivations

Believe it or not, developers make design choices every day: a thousand micro-decisions on how to implement design specifications practically and achieve the desired user experience outcome. They often spend more time with the design material than even the designers themselves! To get in the developer’s head, we must recognize that they base their decisions on:

Elegant engineering—Unlike design which focuses on external human perception and feeling, engineering elegance is measured internally. Code should incorporate modern principles, such as object-oriented programming (OOP), modular design, etc.
Simplicity— Code should be simple, ideally following the principle of “don’t repeat yourself” (DRY).
Done-right approach—Application development should incorporate as much specific technological best-practices as possible.
Proper architecture—The application architecture should meaningfully apply to the problems it aims to solve, including components interconnections, modules, etc.

Designers’ motivations

In our story, the designer was too focused on pleasing the client to be able to achieve successful, practical designs. Rather than prioritising the client’s subjective opinions, a good designer bases their actions on:

Advocating for the user—The greatest responsibility for a UX designer is to keep the user’s best interests at heart. Everything else is secondary, including making the client happy!
Aesthetics—Designers tend to be the ones most aware of aesthetics: style, beauty, and human perception.
Consistency—If modern digital interfaces are thought of as a system of graphical information, the designer’s job is to establish consistency throughout the whole system.
Usability—The designer, if no one else, must maximize the usability potential of a product for humans with a range of abilities and ways of experiencing the world.

Shared motivations

No matter their role, all members of the development team are ultimately working toward the same goals. Whenever an internal conflict arises, it always helps to refocus on:

Project success—If a project doesn’t meet its goals the whole team is affected, regardless of who’s to blame.
Product metrics—Measurable objectives help the team to make better decisions on where to invest their effort, and how to negotiate priorities.
Positive impact—As technologists we have the power to influence the future. In the best case, that means designing and building technology that improves the world in some way.
Team relationships—At the end of the day, mutual respect with colleagues is more important than trivial conflicts.

Mindset

Each specialist on the team offers their own valuable expertise. By working together, the development team as a whole is greater than the sum of its parts.

/uploads/stories/developer-vs-designer-dot-finding-the-common-ground/figure1.jpg?1651176323939

Consider the diagram of overlapping circles used to visualize the Human-Centred Design (HCD) framework. “Desirability” represents concern for the user, and how they will receive the product. “Feasibility” represents the technical aspects, and whether the solutions will work. “Viability” represents the business, and how to predict and measure success. Bearing in mind all three areas, each member of the development team should contribute within their area of expertise and trust their counterparts to do the same.

/uploads/stories/developer-vs-designer-dot-finding-the-common-ground/figure2.jpg?1651176393791

When collaborating between design and engineering, both sides must realise that they are each essential to achieve a successful product. Dan Olsen’s Hierarchy of Web User Needs illustrates how the lower-level needs must first be satisfied by engineering in order to decrease the users’ dissatisfaction to an acceptable threshold. Only then can the product go above and beyond by providing a well-designed feature set and excellent usability.

/uploads/stories/developer-vs-designer-dot-finding-the-common-ground/figure3.jpg?1651176496061

To further enhance the product development culture, designers and developers alike can champion agile principles. In essence this means being flexible enough to adapt to a changing situation. If we have learned anything from the dramatic disruptions of the 2020’s so far, it’s that businesses must be resilient against radical changes in customer behavior. Rather than working in drawn-out “waterfall” phases like the team in our story, working in tighter agile cycles allows the team to make informed decisions about the right next actions at any given time.

Tactics

Finding the common ground between developer and designer takes proactive effort on both sides.

What you as a developer can do

Push for budgeting designer time through implementation. Don’t let yourself be caught in a situation where you’re expected to do the job of a designer yourself, with no formal support.
Establish a Design QA workflow. Any user stories that involve UI implementation can be automatically assigned to a designer for inspection.
Invite designers to demos. Make sure design is aware of the work in progress, and keep an agile mindset.

What you as a designer can do

Include engineering early in business and design talks. Don’t make the mistake of designing all the bells and whistles without validating the technical feasibility.
Hold regular cross-functional team working sessions. The team produces stronger work together than when kept isolated.
Invite dev team members to design critiques and user tests. Direct contact with the end-users builds empathy, and keeps everyone’s focus on the real-world impact of their product.

In conclusion

Most conflicts between development and design usually arise from a lack of understanding. Foster a culture of communication by showing an interest your counterparts’ area of expertise, and in turn be welcoming to their questions and suggestions. Try to see things from their perspective by considering the motivators that are driving their actions, and always keep in mind the big picture of working towards project success together as a team.