As a web developer, I frequently have reason to curse web graphic designers. That’s not because I don’t appreciate their talents. I love working on great looking designs and I have a lot of respect for those who can create them. But designers don’t always understand the limitations of technology, and how their decisions can make life hard (or easy) for developers. So here’s 10 tips for how to create and document designs in a way that will earn you much developer love.
(I’ve assumed you are creating your designs as sets of PSDs to be sent to a web application developer, but I hope at least some of the advice will still be relevant if that isn’t the case.)
- Find out what tools your developer has. Many developers don’t have the budget to shell out for a full Photoshop licence just to be able to open design files. PSDs can be opened with other software, such as the indespensible (and free) Irfanview, but then the full range of information buried in the PSDs will not be readily accessible. If you don’t know who’ll be doing the development, assume the worst.
- Identify all colour and font choices. A PSD or other document with colour swatches and all the fonts named will save a lot of developer time. When choosing fonts, try to pick web-safe fonts wherever possible. (If need be, make it clear to clients that requiring other specific fonts on titles may add considerably to the cost of a site, and using them on body text may not be practical at all – unless the site is to be done entirely in Flash, which has other disadvantages as well as cost).
- Show dynamic elements. Include pull-downs, pop-ups and rollovers in your design documents. Don’t forget that form elements and links can have mouse-over properties as well as menus.
- Document all link colour properties. Links can have up to five different styles depending on their state: normal, visited, active, hover and focus. Document how you want these to look, bearing in mind that they convey information to users. Making them all look the same for aesthetic reasons will make them less useful.
- Provide style guides. Document sample body text showing all levels of heading, numbered and unnumbered lists. How should linked headings be distinguished from normal ones? Likewise for forms, showing how labels should appear relative to input areas, button placement and so on. Remember that the space between elements needs to be specified as well as their sizes.
- Think before you flatten an image. When you merge layers you may remove valuable information and hence make life harder for a developer. As a general rule, don’t merge text and background layers. If you have to merge layers to keep a document size within bounds, copy the component parts to a separate document first and save it: let your developer have all such working documents if possible.
- Work at the right resolution. I’ve had design images supplied to me at twice normal resolution “for better quality”. It doesn’t work. What is the developer supposed to do, for example, if the original design shows a border 3 pixels wide? Should it be one or two pixels wide in the actual page? (No, there’s no such thing as half a pixel!)
- Keep things consistent. Don’t vary the layout from page to page without a good reason to do so. Reuse design elements as much as possible. Bear in mind that the developer won’t be constructing each page by hand but instead creating or configuring software components. Every variation adds extra cost to the implementation.
- Allow for resizing. If you draw a bounding box for text, consider what will happen if its contents are much longer or shorter than in your design (or the user chooses a different font size for ease of reading). If possible, show the different cases in your design documents, or at least give some thought to them. Vertical gradients may also cause problems for the developer when elements are resized, as background colours of sliced images may fail to line up and match when they are shifted. (Horizontal gradients may also be an issue in floating width layouts).
- Favour simplicity. Yes, those rounded corners, bevels, shadows, reflections and gradients look cool and impress the client, but do they really add much to the usability and appeal of the site? Every extra detail causes more work for the developer, especially in ensuring all the pages work across browsers. And the finer points of your design may well be lost on end users, who aren’t visiting to admire the aesthetics but to use the application. (Consider how many of the most enduringly popular web sites are fairly plain or downright ugly, and swallow your pride! Any site aimed at a design-savvy audience is an exception, of course.)
OK, that’s my say for the end of 2008. So, designers: what can we developers do to help make your lives better?