Next to the relationship between man and woman, there’s probably no two groups of people who understand each other less than designers and developers. Yet there is very little literature about the subject and surprisingly very little debate. Why this problem get so little attention isn’t easy to answer but 5 years after having co-founded a now 60 man tall agency I am beginning to understand why some of the issues exist and why we avoid them.
Some time ago we did some work for a company that has developed a virtual PBX. This PBX allows companies to skip all the hardware and wiring that normally needs to be physically installed when setting up a phone system. By simply downloading an application and buying a set of cell phones any company can be up and running in a matter of minutes.
One of the projects for this company was an application that allows for anyone in the company to pickup, hang-up or transfer a phone call somewhere else in the company from his or her own computer.
As we got ready for handover and walked through the design with development some of them questioned why the buttons had a different sizes and color. Why no just make them all the same?
The discussion went back and forth as the developer thought it would be better just to create the same types of buttons and furthermore it would be easier to maintain and change. What if we decided to move the buttons further apart? What if we decided to move them somewhere else? There was a long list of reasons why it was better to just make the buttons the same.
The designers stood by their decision claiming that it was better for the user experience to do things this way so the buttons ended up in different sizes and colors.
The example above wont go down in history as the epic battle between developers and designers, but it’s typical of the types of conflicts that happens as designers hand over their work for implementation to developers.
The designers are thinking that what matters is the user experience and delivers what they consider the optimal solution for this. They have been thinking this through quite a lot, has a perfect reason for why buttons are positioned the way they are and look the way they do. What matters to them is that the vision of the experience they had in their heads will find it’s way into the final product.
Now witness the developers. They look at the design they just received and realize that this is a major deviations from the standard types of buttons. They are developing for arcane environments such as XP with SP2. Alpha channels! What planet are the designers living on? Don’t they know?
To the developers what matter is a system that can be easily maintained without to much custom development as it will make it harder for them to change things later on let alone create it in the first place. To them what matters besides many other things is the maintainability of the solution and the thousand other features they have to do.
Now it would be easy to claim that what matters is the end user experience. Why should it matter if it’s harder to maintain? If it’s a better experience for the user, shouldn’t the extra work be justified? Isn’t our customer paying us to create the best possible solutions for their clients?
But this is where some of the differences between the reality of the designer and the developer starts to emerge.
Contrary to popular believe this problem is not simply explained with left brain – right brain differences. Yes it’s popular (especially among ourselves) to talk about how developers are absent of aesthetics and designers of logic. Although this might allude to some of the reasons for why we have the arguments in the first place, it won’t explain what those arguments really are about.
Different planets, different conditions.
If the designers decide that function X in the design has to be changed, it’s fairly easy for them to revise their design files and change them. Even radical changes are no biggie. There’s no functional consequence to the design files as there is no right or wrong way to objectively approach design. No validation process (other than that of their creative director) will realistically help evaluate the design decisions made.
This is not true for development. If developers figure out something has to be changed it can have huge consequences on the time it will take to implement that change. No matter what framework they’ve chosen, with development it comes with both constraints and defaults.
The moment you start to deviate from those it becomes very burdensome to change even minor things. And contrary to design, development can be validated “objectively” (Do function X work or not) and will be, because this is the end of the product development line.
As a consequence developers are obviously very skeptical when it comes to deviating from the boundaries of their frameworks. And even if they aren’t, the ever present release date and next sprint will be a sure wake up call for even the most designer friendly developer.
Interestingly once the design have been implemented it’s fairly easy for developers to change content and styling of content, something that can take quite a lot of time for a designer to do.
But if it’s no biggie for designers to change things why don’t they just listen to the developers and change things to make it easier to develop? This is where things become interesting in a weird kind of way.
A question of metaphors
In his book “Code Complete”, Steven McConnel speaks about metaphors. He reasons that metaphors are necessary to be a good developer as it helps visualize the act of coding. The metaphor he prefers is the “construction” metaphor. This metaphor he argues best explain the act (some would say art) of programming and gives developers a language to speak in that brings clarity to the development process.
When in construction you prepare the building site, lay a foundation, frame the house, put siding and a roof on it, and plumb and wire it. This is equivalent to programming. In other words through the lens of the construction metaphor, the developer is someone who ultimately build someones house by working together with different disciplines (Architects, designers, contractors etc)
In the design world historically, the metaphor that best describe design is “composition”. Just as a composer would; designers talk about rhythm (typography and grids), harmony (color palettes), dissonance (call to action) chord arrangements (page layout) and so on. The clear legacy from the art’s disciplines have formed the language that many designers today communicate in when they speak of and evaluate design.
This has worked out fine for many decades even after the introduction of computers. In print media for instance, the designer would normally deliver something to the DTP guy who would make the desing documents ready for the printer who saw it as his most important job to make the best print possible.
All the way through the process from idea to final rendering a shared understanding of the composition metaphor prevailed. There was no transcendence issue to so speak they shared the same goal and had at least a dozen areas they had comparable knowledge.
But in digital design, things are quite different.
If we take the print process as an analogy to explain the designer-developer-product relationship, it would be like designing your layout, then deliver that to a group of engineers who would then develop a printer that would print out your design exactly they way you had envisioned and specified it.
Or to speak in terms of music composition; it would be like having to debate with members of your orchestra why you decided to notate legato instead of staccato for the passage as it clearly wouldn’t lead up very well to the second act.
Obviously this spells problems for the process (and the ego of the composer), but more importantly, the two different types of metaphors just don’t work together.
I mean when have you last seen a composer give his music to a contractor and ask them to build a house for him that looks exactly like he envisions hears it?
Of course designers and developers are more aligned in their thinking, but for two disciplines that are so depending on each other to get the product done, their metaphors are surprisingly alien to each other.
To get back to the question about why the designers don’t just do what is easiest to implement for the developers. It all comes back to the problem of how the two disciplines see each other and the metaphors they use to frame what they do.
Designers could easily change things in their design, but that would in their mind make the composition a.k.a. the user experience weaker. Which is probably true but hardly as relevant as they would like to imagine and thus the constant fights over the ideal and the real continues.
In search of a different metaphor or a different process?
Could the problem be solved with changing the metaphors?
Obviously one metaphor that springs to mind is “architect” which many UX people consider analogues to their field. But they are normally the ones making the wireframes for the designers and many are frankly even more hostile to the idea of the development framework having any decision power over the experience.
They have run their usability tests on 5 users and with the bible of Jakob Nielsen and Don Norman in their hand they will quote Frank Lloyd Wright ~ “You can use an eraser on the drafting table or a sledge hammer on the construction site.”
Clearly that isn’t much help to anyone, as that is what the developers have been saying all along when referring to consequences for the maintainability, the boundaries with the choice of framework
Making the developers musicians in the orchestra also seems fruitless and wrong as they are in many ways composers themselves of a different type of composition. And they will have opinions about your music, why wouldn’t they? They are the one who have to play it.
Designers are from Venus and developers are from Mars. And they won’t ever really understand each other. A few though have chosen to set differences aside and are working on building diplomatic relationships.
They are the developers who can design enough to appreciate what good design can do for their product even if it sometimes means having to deviate from the framework and put a little extra effort into customizing certain functionality. If they are really good developers they will actually anticipate that they have to deal with it and either use a framework that allow them be more flexible or improve the framework they prefer to work in.
And they are the designers who learn how to think like a programmer when they design and develop an aesthetic that is better suited for deconstruction rather than composition. They know that composition in the webworld is not like composition in the printworld and that what they are really doing is solving problems for customers not manifestations of their creative ego.
What separates the so so developers/designers from the excellent ones is the ability to understand what they do beyond the tools, frameworks and metaphors they use.
May they live long and prosper. Godspeed.