4 secret mistakes web designers make that double developer costs.

If you want lower development costs and quicker turnarounds, it’s time to ditch deficient design practice.

The intangible and immediate nature of web production versus print or even film and video production also means that most clients expect the work fast and cheap. They also expect that “simple” changes can be easily and instantaneously executed at the code level.

You know what? They’re kind of right.

But there’s a problem.

The problem you don’t know you have.

Most of the time, in order to achieve the specific results a designer has outlined in Photoshop, the developer has to work double-time to replicate the effect in a web browser.

This has less to do with developer inexperience and lots to do with common design practices that unwittingly introduce impossible coding solutions; which, in turn, lead to developer “hacks,” never-ending feedback loops about the build “not matching the design,” contentious scope change discussions, and timeline delays.

In these scenarios, cost, expense and aggravation are further compounded with each subsequent copy edit and design change introduced throughout the project lifecycle.

So what are these common pitfalls and what specific problems are they creating?

I’m so glad you asked.

4 design habits to ditch immediately.

Most “web” designers today were raised up in the print tradition and have evolved into digital design.

While some foundational principles will always be relevant, it’s time to ditch the pixel-perfect print approach and learn why some practices just don’t apply.

Quit yer kerning.

Kerning is the process of adjusting the space between pairs of letters to create a more visually appealing result (usually by overriding the default spacing of the typeface, set by the type foundry). It is different from tracking, which applies spacing evenly between all letters.

In CSS (the programming syntax that styles type) there is no function for kerning.

Developer now has two choices for matching design:

1. Apply the letter-spacing property which will create equal spacing between all letter pairs (i.e. tracking) and likely look wrong, or
2. Preserve the kern by importing the text as an image instead, which presents problems for SEO (the search engines don’t read images), load times (images suck bandwidth) and requires that all future updates made to that text be changed first in the source graphic and then re-imported.

The real rub on this one is that kerning is often a painstaking perfectionist pursuit for the designer (read: a labor of love).

When you kern for web you are wasting everybody’s time. If you want to keep your skills sharp, practice here instead: Kern Me.

Here’s a list of other type effects that cannot be supported:

• Stroke or outlines on letters. The effect can be fudged using webkit or bending the text-shadow property in CSS3 to simulate a true stroke, but the former is rarely an exact match and, frankly, creates dev work for little return.
• Stretching, squishing or otherwise distorting text. In graphic software, it’s quite easy to create text distortion effects by resizing the text box but none of these gimmicks can be replicated in the code.
• Vector manipulations. Applying a bias-cut to your capital H might lend well to the design but these kinds of customizations cannot be styled. If you insist, limit this approach to logo designs since it’s more acceptable to insert logos as images.

On the topic of using images for solving text problems:

Retina display devices display greater pixel density. This means that every time an image has to be output (as a workaround for text limitations) it must also be output at multiple sizes in order to prevent pixilated appearance on certain devices, such as iPhone. Whether it’s the designer or developer who takes on this task, it adds unnecessary time to a project and amplifies the effort of all future updates.

Don’t press BLEND.

Layer blending tricks such as “multiply” work in Photoshop because you are applying a single effect to create a gestalt result.

But browsers are not compositing tools and they do not read blends.

Building a website is an exercise of cutting up unique design elements and pasting them back together in hierarchical layers using HTML/CSS. It is precisely because of this cutting and pasting that effects applied “to the whole” cannot be exactly reproduced.

To summarize the blending problem with a simple analogy:

If you break a vase into a thousand pieces and, by some miracle, are able to glue it all back together again, it will always show the seams from where it was cracked.

For the love of Grid, be consistent.

Grids are a great example of monolithic design principles that still bear relevance in the web world.

But unlike print, which is known to apply slight inconsistencies to layout if the change presents better graphically, web needs consistency.

Here’s some examples of how bad layout practice shifts time onto the developer’s side of the line:

1. What’s a grid? If you’re designing without grids at all you’re literally saying to your developer, guess how many pixels down this logo sits! Go ahead, guess! The developer has to waste high-paid developer time measuring the pixels in Photoshop at every step of the way as well as calculating dozens of mathematical outputs (in the era of responsive design) in order to match the results in the code. It’s a bit like hiring Chef Gordon Ramsay to be the dishwasher at your restaurant.
2. Grid-ish. So maybe you’re using a grid but, for whatever reason, decide to stray from said grid on the About Us page because you really really like the look of this super skinny side column in this one instance. For each unique layout introduced by the design, more code has to be written. And guess what? For each update or “fix” to the site, more code has to be cross-checked.
3. H1, not H1.5. The HTML elements for headers are H1, H2, H3, H4, H5, and H6. There is no H1.5 or H3versionB. So when you apply a header style, insist that it’s the same size everywhere it appears in the design. This is true even if the elements must resize for smaller devices, like elements should resize the same.
4. Vertical Rhythm. Like with the header tags, try to apply consistent rules for line-height throughout your design. Establish a single line-height measurement for each of your header elements and for your <p> paragraph text and then live and die by those measurements.

Inconsistency at the design level is the number one reason that most frontend dev fixes come back as incomplete (as in, “it looks okay on the Home page but the problem still isn’t resolved on the About Us page). In a crunched timeline, a developer is racing to address feedback. Updates to a line-height or column-width measurement in an inconsistently designed website means that all changes must be cross-checked against three or four different instances, which is easy to overlook.

In the case of responsive websites, most “inherited” styles are sized relative to an absolute parent calculation (using em), so oddball exceptions have a negative cascading effect of their own.

Account for “chrome.”

By “Chrome” I’m not speaking of Google’s web browser but quite literally the grey stuff at the top of every web and mobile browser. Usually the area where you find browser tabs, bookmarks and the address bar.

Web browsers have chrome and it’s sized differently between browser types and based on the unique settings of the user.

Guess what? Operating systems have “chrome” too. For example, on an iPhone, there’s browser chrome at the top as well as at the bottom of the screen (you know where those bookmark icons sit?). On a Mac, the dock is considered a type of chrome and some people like their application icons to be really BIG.

All these forgotten areas eat up available space on the screen.

So before you promise your client that their mission statement will absolutely sit above the fold, get acquainted with these forgotten measurements and factor them into your layouts. Or better yet, just don’t set unrealistic expectations to begin with.

Some parting words.

For many designers, marketers, account directors, and even digital project managers, what happens “in the code” is still a big black box of mystery.

Equally, many developers don’t always know how to articulate such specific problems as part of their design audit process. Or they think it’s not their place to say and simply inherit the burden at the expense of the project efficiency and all around good working together vibes.

Design files are simply the blueprint or reference point for building a site.

They are used for obtaining measurements, obtaining color values and, as required, exporting source imagery into the site itself (though it’s even better if images are provided as separate assets).

Applying grids, consistent elements and avoiding fancy text effects while designing are just a few strategies that can save a lot of time at the development level and minimize the back-and-forth between developers and designers trying to reach perfection.

If you know a little code yourself, you can also visit Can I Use and rule out more unsupported or under-supported effects upfront.

Oh and one last thing:

The world doesn’t need another custom Twitter icon.

Web-safe social and vector icons can now be pasted into sites with just a single line of code like Google Web Fonts. Font Awesome and IcoMoon are two services who do it well. Save yourself the time and put your focus on design aspects that need a personal touch.

written by @suzanneabate for The Development Factory