As designers, we know how the site should look. Exactly as it looks in the design. However, by learning more about development we can help streamline the coding process, possibly reducing the time to code the site and any complications that may occur.

In this two-part article I will discuss and point out several of the things you as a designer can do during your creative process to ensure nothing is left to the developers imagination.

So you’ve just completed your latest masterpiece, a flawless graphical representation of an incredible website. It is visually stunning, and is ready to be coded. Or is it?

As designers, we know how the site should look. Exactly as it looks in the design. However, by learning more about development we can help streamline the coding process, possibly reducing the time to code the site and any complications that may occur.

Here are the 6 things many designers forget before shipping a design off to be developed, or developing it themselves.

 

Design File Prepwork

Many designers, not all, forget completely about this aspect of the design process. We understand our design, and know what all of the layers represent and which groups translate into pieces of the design. Often during design, we forget that the design file itself needs to be prepped as well. As a developer, I know personally that when a client uses the following guidelines before sending me their files, the job will be easier, and will go faster. It also let’s me know I’m working with a professional.

1. Each design file is named appropriately with the page’s title / name. If you include several page designs in one file, be sure to separate each design by group and label the groups according to the page content.
2. Inside the design files, the layers are organized in groups. Groups help the developer understand exactly which pieces contribute to a certain part of the site. By using groups you make the job of slicing exponentially easier, as the developer can usually toggle the groups visual state to on/off and instantly know what the group is for. Be sure to label groups with names relative to what they do.
3. Within groups, use appropriate layer names. Having a Group named “Header” is a start, but if it is made up of thirty layers with only the title “Layer 1, Layer 2,…” etc., then the developer will still have a hard time trying to identify exactly which layer is which piece of the design. Naming your layers according to their function will save time and energy.

 

Smart Objects / Vectors for Logos and Logotypes

When you include a logo or logotype in your design, chances are it will need to scale. Including it as a smart object or as a separate vector will help the developer during the slicing process should the size provided be too small or too large. They can rescale it on the fly themselves if necessary, without coming back to you and asking for a larger version for this or that reason.

 

Link Styles

Links are easy enough to understand and design. When coding however, we need to know more than just what color and size the links are. This checklist will help you determine if your designs has enough link styles so you leave nothing to the imagination of the developer:

1. Have you specified link colors for normal (link), visited, active, and hover states?
2. Have you specified any differences beside color the links should have when hovered? Such as underlines, movement, or otherwise?
3. Have you given an appropriate title to the link, or note in the design, so the developer knows where the link should go?

 

Form Input Styles

We often design for form inputs, things like search boxes or user login areas are quite common. Like links, inputs need to have designs for states. When we design we sometimes forget about the following items:

1. Focus state. You should include at least a layer, hidden or otherwise, of the input showing it’s state when a user is actively typing within the input.
2. Text. Don’t leave the input empty. We want to know what color the font should be, what style, what size, etc.
3. Focus text. If you want the text to change style when focused, include this.
4. Hover States. For those of you going the extra-mile design wise, include a hover state for the input, for mouseover, including the input and text.

 

Javascript Functionality

This one is becoming more and more relevant in the modern web era. With the advent of tools like jQuery, prototype, mootools, and others, the javascript scene has exploded. Chances are you have at least one area of your site that could use some javascript functionality. How do you let the developer know?

Going back to the basics, you should use a group. Be sure to specify that this group represents an area that should be created with or which uses javascript. For animations, things get a bit tricky.

How you do show the developer you’d like a fade animation instead of a slide? One creative way a client handled this problem before sending a .psd to me was simple, and effective. He created a new text layer, hidden, with a label saying “Javascript Features”. Within this layer he specified exactly what transitions should occur, how long they should take, and any other pertinent visual aspects of scripting that should be noted during development.

Font Size, Family, Padding, Anti-Aliasing, and Images

This one seems so simple, but it often causes a ton of problems.

Have you specified exactly which text you’d like to appear as font on the page, and which you’d like as actual, selectable text? For most of your designs text, you will be using standard browser fonts, to provide accessibility. If you have headings that are in a non-standard font, be sure to let the developer know in the file that you’d like this to be either a) an image, or b) sIFR embeeded text.

Are you using anti-aliasing? Consider the following: many times designs are packed full of content, with text just fitting in a perfect place. This will not translate well, especially if the anti-aliasing in your design in throwing off the actual text-width as seen in a browser. To learn more about anti-aliasing and how it will effect your design on the web, read up here. (Opens in a new window). For the short version, on body text that is sans-serif, or even sans-serif headlines, you should probably use crisp. On serif fonts, for body text you should use no anti-aliasing (for pc rendering) on small fonts, and sharp for larger versions.

When the developer copies text from your design to put into the page, it will likely be a different length, due to the way browsers render text versus Photoshop’s system. Ensure you include a bit of padding in your design in case a line needs to break and go down a row, or otherwise note you’d like the text truncated to fit.

 

Conclusion

That wraps up part-one of this series. I hope you found the article informative and useful in your design process. Remember, the more scenarios we design for, the less likely it is we will be disappointed in the final product. For part-two and more information, stay tuned here at www.designerscouch.org