I'm usually the guy called in to make peace between designers and developers. I have consulted with large enterprises, major IT providers, etc., and my job was to bridge the gap. I have also been one of the Creative Directors at Razorfish, but my job usually starts with presales and meddles with the product managers, designers, and developers.
In short, I can talk the business talks while designing and finish off coding the designs. So, here are what I think.
The war between Designers and Developers will never end, and it is OK. The designers will blame the developers that they are supposed to be smart enough to code the design. At the same time, the developers will scorn that the designers have no clue how things work. The situation aggravates in bigger companies and environments where separate teams by function, not by products or features/modules.
There was a documentary about Aston Martin making the One 77[1]. The engineers, designers, and everyone work together. There are no separate teams that come together later to fit in the final car. A few friends and I used to refer to this analogy when explaining how to get designers and developers to work together -- think of the product/feature/module and then bring the team together from the start.
There should be one person in the team who can walk between the designer and developer world, even if s/he can only either design or write code. S/he should have that empathy to understand both sides of the stories. Once you have that person and the team begin to learn to dance around, the intricacies of interaction between the two different minds will be the time when things get smoother. There will still be friction, but it should become way more manageable.
Over a decade ago, @cdixon tweeted, which has since been deleted, "Desingineer" - mythical person startups are looking for who can do UI, UX, and excellent front-and back-end coding.[1]
This should be a blog post or even one of those mini pay-what-you-like eBooks sold on Gumroad. Let me try a quick and short starter for you.
It is easier to teach designs to developers than vice-versa. "Design" is not what most people think -- artistic. To me, design is more about knowing the key aspects of arranging objects based on symmetry, sequences, and patterns. Once you understand these nuances of spacing objects to form a cohesive and meaningful flow of information, tackle the idea of how typography works. If you grasp these two essential items well, then others will keep flowing on their own, or you will be exploring automatically.
Now, since you can dabble in the front-end, play around and apply your understanding of "design" and experiment. Learn the basics and do not start from "frameworks" such as Bootstrap, which most impatient developers start with. It is indeed OK to be using the likes of Bootstrap but know that someone else wrote that, and you too can write one.
Once you are comfortable with the two worlds, it is then up to you to go deeper and specialize in being the Product UX Engineer or stay a generalist and work/lead other aspiring designers and developers.
I have a friend far better than me in both design and development. He is an engineer with an additional degree in design from one of India's prestigious design institute. When we discuss things, we tend to complete one another, and can dovetail fast enough while I never fail to be amazed by his insights every time we talk. Unlike me who have moved much further to the dark-side of the Business world, he remained a deep specialist in that beautiful realm.
> "Design" is not what most people think -- artistic.
Just wanted to call this out as ABSOLUTELY SPOT-ON!
One additional concept I'd throw at developers is that design is not about making pretty pictures alone. Sure that's a part of it - nobody wants to use something that looks like ass - but in addition to that obvious requirement, you have to convey meaning without using words and do so with patterns, layout, and flow that people are already used to.
For anyone wondering "WTF is he on about here?" check out the study of "iconography". Think of the old school Windows system tray network icon. Two screens with a "link" thingy between them that blinks. Notice how that conveys the idea of computers communicating - aka, a network? That's a fundamental, critical element of UX design.
Now couple that with the need for layout, aesthetics, Gestalt theory (humans like visual symmetry), simplification of the interface for a very wide variety of audiences (elderly, Gen Z/millenials, boomers, everything in between), multiple device types, color theory (in some cultures, for example, colors have different meaning than they do in the West. In China, I've read, you wear white to funerals, not black; what other variances in color meaning may exist worldwide?), various linguistic idiosyncracies in various cultures, etc.
Once you put all that stuff together in your head, it becomes much clearer that UX design is a hell of a lot more than pretty pictures. It's a research discipline, and a field worthy of respect in its own right.
If the software is hella capable but a pain in the ass to use, it's worthless. Why do you think Windows is so much more popular than Linux?
Not to take away from your great post, but that jab at the end felt unnecessary and reductive. There are a million reasons why Windows is more popular than Linux, and while user experience is one of them in my opinion, I'd say it's not one of the most relevant.
Either way, this was a very informative post. I'll be googling these terms as soon as I'm at my desk. Thank you.
It wasn't intended as a jab at all, but I can see how it came across that way. No offense intended, and I do apologize for that. Still, the end-user desktop UX for MacOS and Windows is a major piece of why people use those over Linux as a desktop computing environment. (Nothing wrong with Linux itself mind you, more the ongoing fragmentation, but that's another topic entirely...)
Another important aspect to look at sometime would by typography. In traditional print medium we always used to hear that serif fonts (the ones with the itty bitty hooks on the ends of letters - e.g. Times New Roman) were useful because it helped the eye move along the line. But on computing devices, used to be that the best practice was sans serif fonts (e.g. Helvetica, Arial) because of something to do with the way the fonts get rendered on a screen. That was long before the availability of 4k monitors though, but supposedly it reduces eyestrain and helps with clarity.
I never looked too much into that, and just went with what all the design specialists out there recommended (again, I'm a crap designer). But from this little example we can see that even the shape of the letters themselves plays a role in communicating a variety of things.
Imagine all caps, serif-font, white background, dark blue lettering:
= S M I T H =
FOR OFFICE
Comes across as authoritarian, right?
Now imagine the same in sans-serif, black on white, and maybe "for office" laid out beneath the name on the next line, spaced and sized so that the width of each line is identical:
= S m i t h =
For Office
Comes across as more formal and respectful but less fear inducing, doesn't it? (HN doesn't let me design here so you'll have to use your imagination of course! ;-)
Anyway, this is just a simplified example of how typography not only conveys the words themselves, but an emotional sense along with those words. There's subtext within subtext possible here, and this entire field is dedicated to communicating more than data, and doing so at a very high rate of efficiency - including the things that don't get communicated well through words.
In short, I can talk the business talks while designing and finish off coding the designs. So, here are what I think.
The war between Designers and Developers will never end, and it is OK. The designers will blame the developers that they are supposed to be smart enough to code the design. At the same time, the developers will scorn that the designers have no clue how things work. The situation aggravates in bigger companies and environments where separate teams by function, not by products or features/modules.
There was a documentary about Aston Martin making the One 77[1]. The engineers, designers, and everyone work together. There are no separate teams that come together later to fit in the final car. A few friends and I used to refer to this analogy when explaining how to get designers and developers to work together -- think of the product/feature/module and then bring the team together from the start.
There should be one person in the team who can walk between the designer and developer world, even if s/he can only either design or write code. S/he should have that empathy to understand both sides of the stories. Once you have that person and the team begin to learn to dance around, the intricacies of interaction between the two different minds will be the time when things get smoother. There will still be friction, but it should become way more manageable.
1. https://www.imdb.com/title/tt2289553/