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

Another fun and interesting article from the Webdesigner Depot.
Having been a Web designer first, a Flash developer second and a Programmer/ Web developer third I can relate to this  on both sides of the issue. I can remember reading a ton of  round table discussions back in the day, particularly in Create Magazine, on the Designer vs Programmer issue. Of course back those days ( less than a decade ago) it was much more black and white.
Here’s the  post from WebDesignerDepot, leave a comment let me know what you think.

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.

A few weeks ago, we explored the main pet peeves that web designers have with web developers, and suggested some solutions for them.

Today, we will discuss the other side of the coin: the five most common gripes that developers have with designers.

PEEVE #1: “Why do designers want to create everything in Flash?”

The website is a mere button and some text, but the designer insists on using Flash, even if it triples the downloading time.

Issue
For some designers, using core web technologies (HTML, CSS and JavaScript) to create a web page can feel like the death knell of innovation. They limit their creativity and force them to depend on the developer to realize their vision.

Flash gives designers potentially unlimited design possibilities, and they can retain far more control over the final product, especially if they know ActionScript. With Flash, designers can choose from any typography, tilt and skew elements, add animation and create special effects that are just impossible in boring ol’ HTML.

Solution
The first question to ask yourself as the developer is, “What is the best technical solution to the problem?” It may be core web technologies, or it could be Flash. Having an open mind is important. To determine what would work best, sit down with the designer and agree on a list of technical and design requirements for the project.

For example, explore whether the page has to load quickly, use a particular font for marketing purposes, meet accessibility guidelines or have animation. Once you answer these kinds of questions, you will be better able to weigh the pros and cons of using Flash.

Informing your designer about JavaScript frameworks such as Dojo and jQuery is a good idea. They may not realize the interactive functionality and special effects that can be achieved with AJAX and DHTML.

PEEVE #2:”Has the designer even heard of HTML CSS?”

The designer has created a great design using Photoshop, but the web just doesn’t work that way.

Issue
Some designers seem to be willfully ignorant of even the most fundamental aspects of web technology. This can result in designs that are plain unrealistic or extremely difficult to recreate on the web, that rely too much on images for simple typography or that lead to a subpar user experience.

Solution
CSS is the language of web design, and designers working in the medium really have no excuse not to understand its basics. I liken this to my earlier work in print design. I didn’t have to know how to run one of those mammoth industrial printing presses, but I did have to know about trapping, half-tones and CMYK.

I had to understand the fundamentals of the printing process if I wanted to achieve the best results with my designs. The same is true for web design. Designers don’t need to know how a server works, but they should have basic knowledge of line height, padding, background images and the other factors that make up the web development process.

PEEVE #3: “The designer gave me a PSD with 50,000 unnamed layers and no folders!”

You download the 50 MB Photoshop document, wait five minutes for it to finally open, start to cut a simple button background and are faced with a wall of unidentified layers in seemingly random order and half of which have been turned off.

Issue
Developers have to keep their documents well organized, or else they won’t be effective. However, if something looks right in the view port of Photoshop, then that’s often good enough for the designer. To a developer who is used to object-oriented programming (OOP) and a logical order for code, this can be a nightmare!

Solution
Developers aren’t the only ones who get frustrated by disorganized and cluttered PSD files. As a creative director, I sent back more than one PSD with a request that the designer organize and name all the layers. Address this issue with the designer as early as possible. Make it clear that you will need a clean and organized file.

If that isn’t possible (or the designer is just stubborn), one trick for finding the layer of an object is to right/Ctrl+click it in the view port with the Move tool (the keyboard shortcut is “v”).

A contextual menu of all of the layers and layer groups under the cursor will appear. Select the layer that you want and, if the Layer Palette is open, the correct layer will be highlighted.

I also highly recommend asking designers to learn how to use Photoshop’s Smart Objects. Smart Objects allow you to collect the various layers that make up an object (for example, the layers that contain a button) into a discrete file embedded in the main Photoshop file.

Smart Objects are easy to use and offer several benefits:

• They create an “object-oriented” Photoshop file, in which repeated elements have a single “symbol.”
• They can be output as web-ready elements without the need for messy layer-slicing techniques.
• They make organizing the PSD easier by reducing the number of layers in the master file.

PEEVE #4: “The designer didn’t accommodate for real-world content.”

We are using a CMS system that gives the client full control of the content. The design mockup, though, shows only one line of text for headlines and one paragraph of text for teasers.

The designer expects balanced module heights and columns, but we can’t anticipate the amount of copy that will need to fit there.

Issue
Generating Greeked (or “Lorem Ipsum”) text is a time-honored method of adding realistic-looking content, in the absence of the website’s final copy. However, because it’s not real content, it can lead designers to make erroneous conclusions about the page’s final design.

Solution
Design comps are static, but real-world web pages have to be fluid and dynamic. Designers should recognize this and cover all possible scenarios. This is one of the main limitations of creating static comps: they are not the real thing.

I find it helpful to define the height of areas that will be used to display elements such as headlines and teasers, rather than leaving them open-ended. This will help you ascertain exactly how much space they will take up in the final design.

PEEVE #5: “The designer expects me to guess what styles (s)he has used.”

The designer hands you a comp with no explanation and expects you to figure out the font family, line heights, colors, widths, padding, borders and margins.

Issue
Unlike creating a mockup in Photoshop, web development is generally not done in a WYSIWYG (what you see is what you get) environment. Rather, the developer assigns specific values for measurements, colors and typography.

Solution
I see this breakdown in communication in a lot of projects; it highlights one of the biggest differences between “design” and “development.” Even if the designer used a template with a predefined grid, the developer often has to eyeball other styles.

Having the designer create a style guide as a deliverable, then, is important. The style guide will serve as an agreed-upon blueprint for the design and reduce confusion.

Special Bonus Peeve: “I don’t need no designer telling me how to program!”

The designer wants something done a particular way, whether or not you, the developer, thinks that way is advisable.

Issue
Designers telling developers how to code is just as frustrating as developers telling designers how to do their job. But the line between designer and developer is often thin, and sometimes both roles are vested in the same person.

If you have clearly defined responsibilities for a project, hearing someone who was not involved in the decision-making process second-guess your conclusions is irritating.

Techniques that seem fine to others on the surface don’t always fit the programming environment you’re working in. Explaining the details of your technical decisions takes precious time, when all you want is for the designer to trust that you have made wise decisions.

Solution
Listen to what the designer has to say about technical alternatives; you may not have thought of all of them. More than once, I’ve been in discussions with designers who brought Solutions to the table that I was not aware of, like the first time I saw jQuery in action.

Remember that you and the designer (hopefully) share the same goal of creating the best product possible. If you keep an open mind and a level-headed approach, you can’t go wrong.

Written exclusively for WDD by Jason Cranford Teague