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 Nielson 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.

The front-end developers burden

What burden you might ask ? Well front-enders, are seen like jack of all trades. We sometimes do what the designer or the back-end developer don’t have time to do. Because, well, we are the middle guy, we can do all this, don’t we?

It’s not that I don’t like to do either of these. I have interests in both actually. I really like web design, even if I am not that good at it. I visit mostinspired.com 3 times a week, and I always want to learn new stuff about programmation and new cool scripts. Ajaxrain and Ajaxian are great for that.

Even in our own company, some peoples don’t really understand what we do, i can’t frikking design professionally don’t ask me too, some front-end might, i don’t! I am not a designer nor a fully experienced c# or php developer. I’m glad to help, but when you put me under pressure for these things it’ s just not fun anymore.

Most of the time we also have to integrate all the website content in the CMS. Which sometimes means 50 pages+. And I can tell you that it’s not going to make us throw big smiles of fun. Being in a small company, that often happens to me.

That is our burden.

We are the masters of XHTML/CSS, PSD slicing, website architecturing, HTML semantic, Javascript and CMS. We know what’s possible and what’s not from the start as term of design and features. We are the masters of debugging every browser, even internet explorer 6…

But we’re sometimes designers, developers and secretaries. Just don’t expect us to code a back-end application in an afternoon or to become a traductor/writer because the content guy didn’t do is job properly.

30 Web Design SEO Tips

Tip No. 1

Study and read everything possible about advanced SEO techniques right from the start of your project.

Tip No. 2

keep in mind that designs are cool, but what is equally important is the code that goes behind it.

Tip No. 3

keep the code optimized, check for W3C compliance right from the start.

Tip No. 4

the basics, titles, meta tags are still important if not ignored, so keep space for them.

Tip No. 5

Keep a horizontal directory structure, don’t go too deep with them, the search engines likes easy access to any file in the quickest time.

Tip No. 6

When you name the files and directories, keep it descriptive and simple. Keep away numbers and weird characters.

Tip No. 7

Images better be optimized for size, and quick loading. If you can’t keep away from loading that fancy graphic, mix it with the page elements. Don’t make them look blunt.

Tip No. 8

Make room for a lot of text. As you already know, search engines love text, lot of them.

Tip No. 9

Flash files are cool. And Search engines have found better ways to crawl and index them unlike old times, but that doesn’t mean you can use them extensively blocking access to relevant text info. So if you are keen on using flash, keep alternate text versions ready.

Tip No. 10

If you have dynamic content, make sure you keep it simple and split to parts. Also, make sure you have optimized static pages for your primary keywords.

Tip No. 11

Always do a bit of competition analysis. See what your competition is, if they have a minimalistic design you don’t want to have a flash design, and leaving no room for improvement. Stalk your competition.

Tip No. 12

Many web designers make the mistake of using a template through out the site and many a times this includes repeating the same title or similar page titles all over the site. Get over this, use descriptive page titles everywhere possible.

Tip No. 13

Keep the page titles to 65 characters or less in count. Nothing wrong is going over it, but you could avoid a spill over.

Tip No. 14

The meta descriptions are supposed to be mini ad-copies that should be descriptive of what the page is about. Don’t keep them the same for all pages.

Tip No. 15

Keep the JavaScript away from navigation menu. Navigation menu is a good resource for gathering information about what your site is about, and using javascript can make it less crawlable by the engines.

Tip No. 16

Use CSS based navigation if you want fancy effects. Pretty much all of the javasript stuff can be done on CSS, in a more search engines friendly way.

Tip No. 17

Use the header tags effectively. Don’t limit yourself with H1 and H2. Use H3, H4 and beyond and use it wisely on the page.

Tip No. 18

Use strong tags wisely. Don’t let them stand out like bolded text, within the content, style it down to show up as normal text within the content.

Tip No. 19

Use the footer effectively. Of course, you can use it for all your TOS/Legal stuff, but also use it to link to the important pages on your site. It helps.

Tip No. 20

Identify the most important pages on your site as seen by the search engines, and leverage them to promote other resource pages.

Tip No. 21

Link well internally, and use descriptive anchor text instead of “click here” and “check this out” like phrases.

Tip No. 22

Use al tags, Title tags on images and use descriptive filenames. They help search engines find more information about them.

Tip No. 23

Use a SEO friendly layout, at least one that does not block or hinder the crawling of crucial areas on your site.

Tip No. 24

Find out the important areas on your website, like the content rich area in the center and keep them above the fold. Not only helps the engines but the user as well.

Tip No. 25

When designing dynamic pages, try to stick to pages with descriptive URLs and not the one with session ids and other parameters. Google can still get it’s head around them, but its good if you can stick to SE friendly, descriptive ones.

Tip No. 26

When dealing with CMS’s there might be instances where you have to keep the page URL the default way with the extra parameters. Use URL rewrite mod to re write the most important pages URL’s to SE friendly form.

Tip No. 27

When using AJAX, load the modules in parts split across pages and not in one single page. Although this defeats the purpose of using AJAX in the first place, you might be able to provide more information to the search engines using other on site SEO parameters.

Tip No. 28

If you want to block any particular area on your site from the reach of Google spiders, use either Robots.txt commands, or else set up a login access. This is the safest way to block crawlers from spidering vital information.

Tip No. 29

Keep the meta descriptions descriptive and precise to about 150 characters.

Tip No.30
Use an SEO simulator to test your design through out the process. And make sure no part of the design blocks/hinders any part of information being accessible to the search engines.

So essentially, web designers got to ensure that while their designs are unique and eye-catchy, making sure that there is enough information available in the form of text is always recommended, and leveraging this information by using all the possible SEO metrics in a healthy and balanced way to cater to the search engines is the right way of designing a search engine friendly web design.