Coders vs. Designer – the “Yin and Yang” of Digital Product Development

by Ciprian Paraschiv on 20th November, 2015

Web design

As things nowadays are getting more and more complex, great achievements can only be gained by placing at the same table minds that can build different perspectives of the big picture of the intended product. Innovation by serendipity is a matter of the past; instead, team synergies need to be unlocked in an iterative process.

One of the hardest complementarity that needs to be reconciled is the one between programmers and designers, the “yin and yang” of digital products. Both typologies grow strong characters, both develop elitist attitudes; both believe that one aspect is more important than the other. Designer doubt when coders come up with graphic solutions, experienced coders are skeptical when designers speak about architecture.

The truth is they both need each other for highest potential to be achieved.

It’s risky

Imagine you are one of the high-minded designers who believes he is by far the legitimate people to decide on how the product should look like. You spend some time of intense efforts and come up with the result that you are proud of. What you don’t realize is that your design may bring up technical challenges that can increase quite a lot the development time. You can even come up with solutions that simply can’t be built. The developer will start coding, but this can turn into a to-and-fro between the two, as the developer will need to bridge the gap between what should and what can be built.

The developer can bring up technical leverages a designer may not be aware of

Technology evolves fast. Designers may dismiss features that were difficult to build in past projects which are now forthcoming. Not engaging you developers in the design process can harm your capacity to innovate, and your business, regarding of its field, cannot afford it.

By continually working with developers, a designer will develop, little by little, some technical background that will become more and more helpful in the decisions they will have to make.

Like it or not, we must admit developers always make decisions that impact design during a project. Include developers as early as possible in the design process and it will be much more easy to get to a consensus when mismatches occur.

Often, developers are strong analytical persons and their pragmatism can prove to be useful, especially when you have to cut from a long list of possible solutions.

On the other hand, there is also a risk if you give the developer too much credit, especially if they are disengaged. There will always be the risk that they will favor features that are easier to build to avoid future headaches. When it comes to simplifying things, this can prove to be quite a great challenge. You need to discern when a developer places on top his personal interest.

Developers will fell more engaged

It can be frustrating for a developer to build something that won’t be used, especially if they just coded what others said. Too often, they are the last ones in a long chain of decisions making. This can translate into a lack of ownership for the final product, a lack of engagement especially in phases of the project when the pressure is high when the team should function like a Swiss watch. And you can’t blame them. It’s not their fault.

What you can do instead is to lend an ear to their voice as early as possible in the project. Encourage them when they make a display of engagement, even though their solution may not be the best one. Use facts and clear rationality when arguing that their solution may not be the best one. Make them know that they are part of the product they build. This is one of the pillars of Lean manufacturing, the design process that proved to be so successful at Toyota.

Ciprian Paraschiv


I am a breed of SEO specialist and UX Design advocate. My strong engineering knowledge is key to reconcile the distinct goals of the two areas. I design with user’s delight in my mind, while not averting from optimizing conversion rates.