Skip to content
Sitemason - Build on Us

Designing for a Successful Web Project

Illustration by Kevin Kennedy -

Illustration by Kevin Kennedy,

At Sitemason, we're lucky to work with a lot of really talented design partners. We also work with designers at various stages in their career. When working with beginners, we often see folks with tons of design talent, but sometimes they're a little green when it comes to designing for a successful web project.

Below we consider design best practices for a project's ultimate success from the view of the client and web developer. Two areas Sitemason is intimately involved during a project lifecycle.

The fewer design decisions a developer has to make, the better

Your home fix-it guy might in fact be a fantastic painter, but if you hired him to fix a hole in your drywall, and he couldn't match the paint color and decides to simply repaint the house this new color, you'd be pretty peeved. It might seem like a basic assumption that Mr. Fix-it should not paint the house without approval, but he thought he was doing you a favor and now he's out a bunch of time and paint, and you have a house color you don't want.

The same goes for web design. A design should leave nothing to chance and include detailed instructions where there might be any ambiguity for the intended behavior.

Understand development enough to know when you're adding cost with your design

As a designer, you don't have to know any code, but you do need to understand when you're adding cost to a project. A designer might be within budget but inadvertently doubles the development cost with their design decisions.

A classic example of a design decision that inflates cost is separate, or very different designs, from one layout to the next. This may be visually stunning, but a designer needs to know that for every unique page layout, the development costs are inflated by as much as 100%.

The golden ratio for development costs is for every hour spent in design, expect at least an hour spent in development.

Layers, Layers, Layers

The single best habit a designer can adopt, as far as a developer is concerned, is to put everything in its own layer.

A developer slicing up a design is going to need to regularly show/hide layers to access all the design assets. Take a standard button for example. A button usually has at least three layers; the button image, the button active state, and the button text. If all three were combined into a single layer, the developer couldn't reuse the button elsewhere on the site, adding time to a project.

Organizing Layers and Files

Example of Photoshop LayersSince you're going to have so many layers, the next best favor you can do for a developer is to neatly organize your layers into intuitive groups. The above button example should be in its own group, as well as a page layout should have its own group with many sub-groups. The groupings should be similar to the site map of the website or application. At a minimum, each layout like home, interior, blog, etc. should be in its own group.

Organizing Files is simple… there should only be one file! Unless there's a real good reason for it, don't send a developer 5 different Photoshop files if they could be combined into one using groups. Sending 5 means a developer has to slice 5, which is a major duplication of work and will increase costs significantly.

If you are including other assets when sending your design file, like a site map, font files, copy, etc, include a README.txt file that explains every file included and its purpose. Finally, package up all your assets into a single compressed file like ZIP or TAR before sending to your developer.

Photoshop vs. InDesign vs. Illustrator

The argument for using one graphic design tool over another is a giant can of worms that I don't want to open. I will simply state that as of 2013, Photoshop is still the dominant, and in many circles expected, file format developers will receive for slicing into HTML. That says nothing about the merits of each, but do know that you are immediately reducing the size of your developer pool by designing in something other than Photoshop.

Use real content for placeholder copy

As a designer, it's probably not your job to mess with copy, but designs have to realistically expect content related to the brand. Most designers will throw in Lorem Ipsum text or static sized images as placeholder, but that doesn't consider the dynamic nature of content. Use a brand's existing website or brochure to populate your placeholder content.

Using real content will give the designs added context and life. More importantly, you will avoid design revisions once end-users add real content, and find it doesn't fit within the constraints of the placeholder copy. 

Mobile First and Responsive Design

Mobile First and Responsive Web Design at abookapart.comForm follows function, and a great way to prioritize brand messaging is to start with a limited canvas. That's what the "Mobile First" movement bestows. If you're designing for a limited space, you'll concentrate on the most important messages first. A Book Apart has literally written the books on Mobile First and Responsive Design. They're short reads and well worth the investment.

The larger point for mentioning responsive design, and mobile sites in general, is because mobile front-end development gets complicated quickly. By designing for mobile first and expanding outward, the relationship of design elements will be more evident between the mobile and desktop versions of the site. But remember! Don't assume the developer will connect those relationships correctly. If there is any ambiguity, write detailed instructions or have that conversation directly with your developer.

Style Guides

Screenshot of style guide from paulrobertlloyd.comI have literally never seen a design that takes into consideration every content type an end-user might add once they get access to the site. It's impossible because users are unpredictable. They'll get a wild hair and want to add a video inside a table with a caption and a button. There are too many combinations to realistically design for total coverage. To address this, and more importantly, to increase the likelihood that the integrity of the design will be maintained, we recommend including a Style Guide with all site designs.

A Style Guide is a one-page treatment of common content types. These should take into account things like form fields, pagination, table data, quotations, code display, etc. There are over one hundred HTML tag types, and the more of them represented in a design, the better. Example Style Guides on the web are here, here, and here. These styles are often provided in a generic layout, like an interior page at full-width.

Include All Font Files

There are a lot of fonts out there. As a designer, you have probably had experience with hundreds of them, and quite a few that you know well and use often. However, a font that you consider popular could very well be a font a developer has never encountered. If you use a font, any font, outside of the standard HTML fonts, include the font files when sending designs to your developer. Even better, choose a web font from Typekit or Google Fonts so the developer doesn't have to make any font decisions at all.

Other Considerations

Font Icons by Kevin Kennedy, strazi.orgOther recent design considerations for the web include providing high resolution images for retina display, using font icons instead of images for ultimate flexibility on any screen size, and design for a common framework your developer may use, like Bootstrap or Blueprint.

There is an excellent article at Smashing Magazine that discusses design etiquette for the web which I highly recommend. It also links to, a great site of best practices when designing for a successful web project.

Billy White headshot thumbnail

Billy is a web developer and Chief Product Officer (CPO) at Sitemason, and has been with the company since 2006.  Read more about Billy White.

Contact Billy:

Recent Forum Posts

Warning: file_get_contents( failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /mnt/files/s/ on line 11 Warning: usort() expects parameter 1 to be array, null given in /mnt/files/s/ on line 14 Warning: Invalid argument supplied for foreach() in /mnt/files/s/ on line 17