5 Pet Peeves Designers Have With Developers (and How to Avoid Them)

Cats and dogs. Cain and Abel. Designers and developers. These are just a few of the great historical face-offs.

Designers and developers often seem to come from different planets and have completely different brains.

Developers want a website to work right, designers want it to look right.

While these goals have a lot of overlap (and, of course, I’m stereotyping here a bit), the differences often come down to the designer and developer’s expectations of success.

Managing expectations is a matter of communication: making points clearly to the other side, finding common ground, and agreeing on goals.

Okay, so maybe it’s not that easy, but it is important for both sides to at least try to understand each other.

In an effort to promote goodwill between designers and developers, I will share some pet peeves I have encountered and explore the issues that lead to them and their solutions.

Peeve #1: ​“Why can’t the developer just make it look like the comp?”

You create a great-looking design and hand off the comp to your developer, but when you get the site back, it looks like a patchwork quilt of what you designed.

Issue
Comps are not Web pages; they are not a mixture of HTML, CSS, and JavaScript code. Photoshop, Fireworks, and Illustrator can do a lot of things that are impossible (or at least wildly impractical) on the Web, which often means that developers will have to scale down the design.

Solution
Talk to your developer while you are designing, not just afterward. Ask them whether an effect you are using will be easy to accomplish or whether a better alternative exists. Also, as you learn more about Web development, you’ll be able to better tell the difference between when your design is impractical and when the developer is just slacking off.

Peeve #2: ​“The colors are all wrong!”

You don’t choose colors arbitrarily, but developers seem to think that ​“close is close enough.”

Issue
I don’t know whether this is true of all developers, but I once worked with a developer who was red-green color-blind (he was a huge fan of our content manager, who sent all of her emails in pink text on a lime-green background). However, being color-blind didn’t stop him from being a kick-ass developer.

Solution
If you want the colors to be right, then spell out all of the color values on the page. Don’t rely on your developer to eyeball the color values or to sample the colors in Photoshop.

You also need to consider that the problem may not be with the developer but with you. Colors look different on a Mac and in CMYK (if you happen to accidentally enable that color space). Make sure that your document color mode and proofs are set to generic RGB by default.

Peeve #3: ​“Do developers even know what ​‘white space’ means?”

You’ve left plenty of breathing room around elements to create a fluid eye path and improve readability, but the developer crams everything together, telling you, ​“It’s the only way it will all fit.”

Issue
I once complained to a developer that he left no space between the border of a module and its content, making it really difficult for most people to read. He replied, ​“I don’t care about other people. I can read it.” While most developers are not quite so callous, they have not been trained in the fine art of mixing positive and negative spaces to guide the visitor’s eye around the design.

Solution
If you really want your designs to be as precise as possible, don’t just give the designer a comp and expect them to figure out the spacing. Specify the exact widths, heights, and lengths in a design specifications document. This serves as a blueprint that you and the developer agree on for how things should be spaced.

At the very least, define general rules for margins and padding. For example, ​“All modules must have a minimum of 10 pixels of padding between the content and the border.”

Peeve #4: ​“The developer can never get my designs to look the same in different browsers.”

You look at the site in Firefox and it looks fine, but when you switch to Internet Explorer it falls to pieces.

Issue
You have to be sympathetic to the plight of developers when it comes to making designs look consistent across browsers. Each browser has its own quirks with spacing. Things are getting better (especially with the slow death of Internet Explorer 6), but getting them all to completely play nice with each other is still hard.

Solution
I generally allow a few pixels of wiggle room in my designs to accommodate cross-browser issues, but it helps to know what these issues are while you’re designing, so that you can help the developer avoid them.

Don’t be afraid to point out cross-browser problems to the developer and expect them to be fixed. But resolving some of them may require that you tweak your design.

Peeve #5: ​“This will take how long?”

Nothing is more depressing than burning the midnight oil on double-time to get your part of a project done on schedule, only to get back a development LOE (Level of Effort) that puts the project release date back a month from the end of eternity.

Issue
In a classic episode of Star Trek: The Next Generation, Scotty explains the facts of engineering life to Geordi La Forge: ​“You didn’t tell him [Captain Picard] how long it would really take, did you? Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.” Some developers think of designers in the same way that Scotty thinks of Starfleet Captains.

Solution
Developers know they will encounter unforeseen problems and so tend to grossly pad their estimates. This also makes them look really good if they get their end done a lot earlier than estimated. Haggle with the developer down to a reasonable timeline and then hold them to it. As you get to know a developer, you will hopefully find your own way to be a ​“miracle worker”.

Special Bonus Peeve: ​“Developers just don’t understand designers.”

Or worse:
​“The developer thinks they’re a designer!”
It’s bad enough when developers seem to simply refuse to see the designer’s point of view, but that difference of opinion can usually be mediated (usually by a good project manager). However, when the developer thinks they know more about design than the designer, tempers can flare.

Issue
I’ve had to deal with more than one developer who read an article by Jakob Nielsen and then wanted to lecture me about good design practice in the middle of a meeting. This not only shows disrespect for the designer but slows down the project as debate ensues.

Solution
Working with know-it-all developers is tricky, and the way to handle these situations depends on the size of the ego you are dealing with. Generally, I find it best to simply listen to what they have to say and then, if they have a point, acknowledge it and move on. Avoid arguing with them if possible.

Often their complaint is about a design ​“rule” that’s been broken. Don’t be afraid to acknowledge that you broke a rule — that’s what innovative designers do — but make sure you can justify why you broke it.

Whenever I find myself in this situation, I think back to my review days in design school, when I had to defend my work against some pretty brutal criticism. These sessions were often ego-bruising, but they taught me how to quickly defend my decisions while keeping my cool.

It may seem humiliating to have to constantly justify your decisions, but the more you show the ​“method in your madness,” the more you will find that your colleagues value and trust your judgment.

Written exclusively for WDD by Jason Cranford Teague.

Which pet peeves do you have with developers? We’d love to know more about this, please share your comments below.