Designers and engineers aren't that different
This post made the rounds at work the other day and on twitter. It’s a well thought out piece trying to address the challenges and conflicts that often arise between designers and developers.
The thing is that I don’t think designers and developers are as different as they often see one another. Sure in the extremely hyperbolic stereotypes they are completely oil and water. But today these stereotypes are mostly throwbacks to an era when software didn’t have much design, and design was relegated to graphics arts and flash sites, not a deep part of both the aesthetics and interactivity of our products. Things have changed tremendously, and I think for the most part the developers who lead our industry have changed tremendously since the good ‘ol neckbeard days.
Here were my thoughts and additions to the original post which I sent around in response, please note that I use the term “engineer” loosely because the original author did. I recognize that In many ways software developers are not engineers in the traditional sense of the word…
A very good read. I’ll add the following personal experience thoughts of my own:
Be understood not just specific
It’s more important to be understandable and give clear reasoning than to just be specific. Specifically pointing out that something needs to moved be 12px top-wise isn’t as valuable as ensuring they understand why the positioning is important or problematic. No one likes to waste time doing someone else’s busy work, so it’s important to understand the value so no one feels they are doing busy work. And while fit and finish is certainly not always busy work, occasionally it actually is. Make sure it isn’t first.
There is some value in answering “no”
The engineer’s gut reaction of stating “no” isn’t always meant as absolute but rather a placeholder for a further discussion towards a better understanding of the problem being addressed by said design. Seek the understanding, not to avoid the conflict altogether.
I used to work with an interaction designer who after a few weeks of working with me told me she finally “got me”. She said “you say ‘no’ to at least half of everything I suggest, then you go sit over there (pointing to my desk) for an hour or two and come back to tell me ‘yes’ and explain why you’ve changed your mind”. Which, for the most part is true of me. I don’t tend to literally say “no” but I do have a habit of throwing out a few early challenges as well as alternatives that come to mind to see if the original idea can survive a few rounds of scrutiny. Afterwards, I find I have a much better understanding of the design and how it fits into the architecture. For me, it is a very important part of the process of understanding the design in order to actually ensure I am able to implement well. More importantly challenging someone else’s ideas and then proving myself wrong helps me to develop more confidence in the idea, and gain better respect and understanding of that person’s work, which in turn makes it easier to trust them in the future.
Conflict itself is a big part of building a solid professional relationship, if your professional relationships can’t handle a bit of conflict then they are not going to develop much at all.
Development is design
Finally, I’d argue software developers are actually “designers” themselves. Creating software is largely a systems design process, and traditional engineering analogies are often come up short in describing how it works (though I do realize traditional engineering is itself a design process too which only further supports the point). Developers and designers really think far more alike than I think some people realize, and most of the advice in that post that is good for designers is also valuable for developers and vice-versa. I’ve seen designers give an emphatic “no” to developer ideas too. It is equally frustrating to have the domain and systems knowledge a developer brings to product development dismissed simply because they are not wearing the designer hat.
I think it is the similarities and not the differences which lead the two groups to butt heads so much. We are are working two sides of the same coin and trying to meet up successfully in the middle with a single coherent design. Collisions are bound to occur. Besides, if you think design and development have conflict issues, just watch some developers go at it ;-). Oh, also beer, obviously beer can solve anything.