Blog:

In design circles, a perennial topic of discussion is How to Deal with Developers. This conversation always amuses me, since the developers I’ve worked with have, in many ways, been much more reasonable and less difficult than most of the designers I’ve worked with. And I’m a designer myself! Dealing with developers usually involves a reasonable, albeit sometimes socially-awkward, conversation. There’s occasionally been anger and resentment, sure, but seldom the sulking, yelling, and flat-out bad behavior I’ve seen some designers (full disclosure: me too) engage in. Why is this?

This isn’t to say, of course, that all developers are easygoing or that all designers are a pain in the backside. But designers as a breed do have their quirks, and I thought I’d share some of them with my developer colleagues so that the next time you’re confronted with a designer furious because his design doesn’t look the same in the prototype as it does in his Illustrator file, you’ll know why he’s acting like that and (hopefully) how to respond.

Trained to be anal

Designers, especially if they went to design school (horrors!), have been trained to be anal retentive. If pixels are out of place, if fonts aren’t right, hell, if spacing between letters is off, someone, somewhere (an art director, another designer, a professor) has torn us a new one over it. And, like an abused child becoming an abusive parent, we often repeat the same cycle. We’re more than happy to rip you a new one if something about our design isn’t as perfect as we pictured it.

We don’t have logical answers for everything

Sometimes, we just think a certain color or a certain way something operates just feels right. “I like the way the font Georgia feels–Arial be damned.” “I think this dark red speaks perfectly about the richness of the site.” These decisions aren’t logical – and most developers are by necessity logical people. Nor, probably, should they always be.

In one sense, designers are paid to have and express emotions within their products. Not every site can look and work like Google, after all. Gut instinct is important to a designer. Most of us have spent years training to trust and hone that instinct, so that we know on an emotional level what works and looks right.

Unfortunately, our instincts sometimes fail us.

Design is a subjective art, subject to whims of fashion and personal taste. Unlike coding, where something works or it doesn’t and it’s usually pretty clear when something is screwed up, it’s harder to tell in with design. Sometimes a design you think you just nailed turns out to be terrible. This is also why a lot of designers are on medication.

Everyone thinks they can design

Because design can be very subjective, everyone feels they can have an opinion on it. When’s the last time an business executive chimed in and told a developer how she should set up her CSS? Designers get that sort of advice all the time and it makes us cranky. We begin with very objective design goals, and then have to translate them into a carefully balanced choreography of subjective design elements. It’s a little reminiscent of a line from the movie Amadeus, when the Emperor comments on Mozart’s latest composition, “Your work is ingenious. It’s quality work. But there are simply too many notes, that’s all. Just cut a few and it will be perfect.” And Mozart responds, “Which few did you have in mind, Majesty?”

Designers secretly want developers to share ownership in the design

We know just as well as you do that if you don’t code it, it ain’t going to come alive. Or if you code it poorly, well, it’s going to suck too.

In the same way screenwriters depend on the actors to make their words really sing, designers depend on developers to make their designs work. Because of that, we want–no, we need–you to understand and love the design like it was your own. If you don’t, well, this can make us insecure. Why don’t you love my baby? She’s beautiful!

But good designers (like good screenwriters) know that good developers can do miracles with material that was so-so to begin with. Any designer worth his or her salt knows that developers often come up with better solutions while coding than the designer did, or twists to the designer’s solutions that really brings them to life.

It’s the economy, stupid

Good designers want what is best and often the most economical (task wise) for the users. But we also know that the ideal solution is one that is economical for everyone: users, developers, operations, customer support, etc. And for that, we need to collaborate.As long as it doesn’t grossly affect the users, most of us are willing to compromise to make the design easier to build and implement. Because, as I said before, we need you more than you need us. Unless it is destructive, a design that never gets built will always be an also-ran to one that did.

Addicts, all

As my colleague Brandon Schauer said to me, design is an addictive yet painful act. There’s an infinite amount of possible solutions, and exactly none of which imagined by the designer will be the absolute best. The only thing that can make designs better is the combination of refinement and iteration. This is the only thing that will get the design anywhere close to the ideal, with time being the only possible arbiter of when a design is considered finished. Changes, fixes, and anguish are all part of the creative process. And you, dear developer, are both a witness to and an enabler of this process. Most designers can’t iterate the living prototype or product without your help. Seeing something live that is ungainly or ugly or just plain stupid makes us weep. It makes us feel like we’ve failed. This is when developers can earn serious points–by helping us fix the problem. We can’t do it alone.

Sympathy for the devil designers

The next time a designer is on a rant about how the font is too big or the check box is supposed to trigger this or that action and you’re puzzled by the vehemence, hopefully you’ll have a better understanding of why. Designers occupy a weird space in the business world: lots of power (to control form and behavior), and yet none (we’re usually dependent on others to execute the design). We care a lot about our designs (we’re not usually in this field for the money) and we want you to care about them as well. We want to be partners with developers and be respected as such. Our common ground is that we all (hopefully) want what’s best for the project. And with a little compromise and understanding on both sides, that can be the case.

Like this article? Digg it!