It’s well known that the clash between Design and Development is not simply just a clash between people who do different stuff- it’s a clash between two ways of solving problems within given constraints.

To really understand what is happening between designers and developers, we need to take a look first at what is each one’s aim and how they think, when it’s different and when it’s similar.

Design’s aim is to accommodate a large number of factors within a single solution (visual appeal, accessibility, usability, marketing, branding, historical and geographical context, etc.) so that the largest possible number of customers will understand and use the solution.

Development’s aim is to direct the complexity and subtlety of a given algorithm towards the same large number of customers so that they will use it as efficiently and effectively as possible.

In contrast to the big and complicated pile of unorganized complexities, a designer has to confront in any project, a developer has to build a process of organized rules that will be incorporated one day in the life of many people afterward (hence, to develop an algorithm). Designers bring those complexities together to build an experimental framework (a prototype) in which developers bring those processes of rules to create a functional prototype.

This is probably the best difference to note if you are just starting out. In order for a solution to be useful, it has to provide efficiency, efficacy and deliver on its promises. In order for the same solution to be usable, it has to appeal to its customers and be understandable enough so that they won’t have to learn the process of rules behind the solution (take, for example, how many people don’t know how a refrigerator works, but everyone has and uses one. This is because the arrangement of controllers is designed in such a way that it easily triggers the process behind the technology, making it ready for use by anyone.)

The main difference between Design’s and Development’s ways of thinking is that Design is inclusive (it has to include multiple factors within the solution) and Development is exclusive (it has to exclude all the possibilities to achieve the ultimate and optimal solution). However, similarities begin here also. In order for those multiple factors and possibilities to be included and excluded respectively, they have to be perceived, which is the reason why a designer or a developer will probably never achieve a state of knowing all there is to know.

Design and Development are, by default, explorative domains, in which there has to be a perpetual state of discovery and learning.

The complex way in which Design and Development have evolved in the past years is due to the rise of all the big communities on the web comprised of people who chose to dedicate their lives to perpetual learning (see communities like Behance and Github.)

But the similarities don’t stop here: Design and Development are also creative domains, they both necessity a large quantity of brainpower and imagination and they are both driven by people who want to make the world a better place and solve problems.

So why the clashes? Why do so many teams and companies find it hard to integrate these two domains who need to work together if they wish to achieve greatness?

It has to do with the fact that what is truly different between these two is the way they approach problems. The design is user-oriented, their focus in on the people and how every aspect of the product will affect them. Development is solution-oriented, their focus is on the problem’s constraints and how to eliminate what is not going to be a part of the solution. The funny part is, both Design and Development will argue that theirs is the way to solve a problem. Development will say that focusing on the people is not literally solving the problem and Design will say that the problem is not really the problem. Both are right and both need to be right.

If Design would start to build solutions the way a developer does, we would have refrigerators that talk about how they work and how intricate and amazing they are as a technology (“.. and also look at my shiny door with three gradients on it”). In contrast, if Development would start to build solutions the way a designer does, we would have database models with flowers and emojis and great typography.

This is no way to start if you want to bridge the gap between them- you can’t ask them to come to terms with the opposite way of doing business since it doesn’t make sense for them to do so. Their approach to the problem is correct for the context in which they apply it. The complex, flamboyant and inclusive process of a designer is perfect for user-centered solutions and the systematical, mathematical and exclusive process of a developer is perfect for solution-centered algorithms.

So how to actually bridge the gap? Well, you might start by giving them this article, which points out the fact that the entire project is by default based on the idea that their approach to the same problem will be different. It’s also essential to understand each and everyone’s limitations so that conflict will not start from ignorance. Encourage your designers and developers (and if you are one of them, do this) to talk with one another about what they can’t do instead of bragging about what they can do.

My high school was a programming high school. The successful kids in my high school ended up to become (obviously) developers. Whenever I had a problem in my IT class, my teacher would tell me to discover for myself, which in my designer mind didn’t make sense because I wanted to communicate about the constraints in order to include them in a final, beautifully coded program. It took me 3 years to understand that this was not the way to do business in that environment and 4 to fully appreciate how the high school shaped my brain.

When my developer buddy left for Holland, the first thing I did was to give him a comprehensive book about design. This is how you actually bridge the gap: by promoting and rewarding understanding of the other one’s point of view so that they will be able to speak freely about the other one’s way of doing business.

In large projects, usually designers are the ones who want to implement intricate features that developers don’t have yet the means of building- developers get angry because designers dream too big and too much and designers get angry because developers don’t want to “get it” when it comes to how those intricate features will help the user.

The truth is, here lies the challenge: making use of everyone’s limitations can be achieved only when both parties understand those limitations. That’s why it’s so important for you to promote this understanding with everyone you work. The only way to achieve greatness is to learn about the stuff you don’t use so that you can integrate the stuff you use within them.