The creative work of designers and the technical work of developers may seem worlds apart. However, there are some important design subtleties that can make or break a developer’s ability to deliver your creative vision on-budget and with minimal revisions needed. This article will explain a few simple things you can do to optimize your designs for web development – ensuring a more polished product, a happier client, happier coders, and a happier you!

Here’s a few tips on providing designs that are ready to go out of the box.

Remember that designing for the web is not the same as designing for print.


Think about your design in terms of ratios and proportions.

With print, your design is viewed directly on the page; with the web, though, your design is displayed through a screen, and the screen one user has may not be the exact same as the screen another user has. Things like brightness, contrast, and even color often display differently on each monitor.

More important: Even though your designs themselves have a set width, the final site will not. It’s important to remember that the site you are designing will be viewed via different browsers and screens with a huge range of sizes — the usual range runs from 320px to around 1920px, but some screens are as wide as 3000px!

Ask your coding partner if he or she uses a CSS framework or grid system like Bootstrap.

twitter-bootstrap-grid-12-columnGrid systems in traditional design help to organize the page so you can easily line up elements, see how they relate to one another, etc. In web design, they’re even more important, because they force you to treat elements proportionally rather than absolutely, which makes responsive adjustments much easier.

For instance, here at Chromaplex, we usually use the Bootstrap grid, which divides the screen horizontally into twelve equal-length columns. Each section has a set amount of padding, known as a gutter, between its left and right neighbor. When you design your page, elements should never bleed into the gutter; they should extend the complete width of however many columns you choose. Let’s say that you’re using a 12-column grid to design a storefront page that lists products. You want to show three items per line. This means that each product should span 4 grid columns (4 grid columns x 3 items = 12 columns). Now, say you want those three products per line to shift to a single product per line for mobile devices. No problem – make a responsive version of the design that shows the products spanning all twelve columns, and now the coder will know how to implement the responsive layout. By using a grid, not only does the site stay consistent, but it also saves development time.

It’s important to note, however, that not all grids use twelve columns. There are fifteen-column grids, sixteen-column grids, and so on. You can specify the number of columns, as well as the padding between the columns, in order to create a grid that works the best for your needs. The important thing is that you’re using the same grid for every design on the site.

Address responsive design

You can do do this in several ways:

You can choose to create multiple designs for various breakpoints. (A breakpoint is a specific screen width where the website will change to fit the smaller or larger size of the viewport.) Here are the standard breakpoints:

  • Mobile phones, < 768px
  • Tablets, 768px to 991px
  • Smaller desktops, 992px to 1199px
  • Larger desktops, >1200px

If you have the time and budget, you may want to create three designs: one for phones, one for tablets, and one for desktops. Doing separate designs like this will not only help you consider how the site should look for each screen but also make it very clear for the coder.

Not all sites are complex enough that it makes sense to spend the time doing separate designs, and sometimes there’s simply not enough budget to spend the time. If you aren’t going to do separate designs, you can simply tell the coder what you want to happen on the smaller screens.


This design is built specifically for mobile.


This design is a desktop design with mobile directions called out.

For instance, if you’re creating a simple blog with a sidebar, it may be enough to say, “On phones and tablets, I want the sidebar to disappear.” Or perhaps you want it to go beneath the primary content. Or perhaps you want it above. The specifics don’t matter, as long as you think about how to handle other viewpoints while you’re designing, and you communicate that clearly to the coder.

The grid system can make communication much easier: if you say something like “on tablet devices, each image in the image gallery should be 4 columns wide,” the coder will immediately know what to do.

Maintain consistency (or create a style guide)

Websites are composed of repeated elements — headings, paragraphs, images, links, buttons, etc. — often with different content. Try your hardest to make sure those elements are consistent across the site.

For instance, if every page has a title near the top, don’t change the font size on a few pages unless you have a specific reason to do so. This often happens unintentionally — you may create a few pages with a heading, then decide the heading is too small, and make a few more pages with a larger title. If you forget to change the font size on your previously created pages, your coder gets mixed messages and ends up confused. As a rule, coders will assume you meant to be consistent, so if you’re breaking consistency on purpose, call that out in some way.


A simple style guide

A simple way to avoid this problem is by creating a style guide, which is simply a “master” design file with examples of styling for all the common elements throughout the site”. You’ll have a page title, a subheading, a sub-subheading, links, visited links, hover effects, buttons, perhaps a few paragraphs — all styled as you want them. Your coder can then use this page as the master guide, so that if any inconsistencies crop up, it’s clear which design should be followed. This also saves you the headache of going back and correcting every design file in cases where you want to make a site-wide design change.

Two caveats here, though. If you want a page title later to deviate from the “official” style, you have to make it known explicitly — otherwise your coder will assume it was a slip-up. Also, you need to remember to update your style guide if you decide to change something!

Fonts! Fonts! Fonts!

You may be surprised to learn that fonts often give coders a lot of trouble. Here are some pointers on how to avoid font problems:

Be sure to include the webfonts with the designs: This is important not only so that the final site looks as you intend it, but without the fonts on our computers, we coders can’t even see your designs as you intended!

Use Google Fonts, Adobe Typekit, or some other webfont service.

Include the various required filetypes — usually TTF/OTF, WOFF, EOT, and SVG. If there’s no webfont available, think seriously about if you can use another font. While font converters exist, they are far from perfect and often cause problems with kerning and font-weight.

Understand how fonts work on the web.

You should stick to whole numbers (15px) for font sizes, line heights, and really anything that needs a number. Decimals (15.35234px) are supported in newer browsers only, and even then each browser handles decimal sizes differently.


The settings within the green boxes can be translated easily to the web.

Font size, line height (leading in Photoshop), and letter spacing (tracking in Photoshop) are supported. Other font attributes g (like, kerning) are not.

Line height (leading) should be used only to specify the distance between lines of text in a paragraph.

Line height should never be used to add spacing (margin or padding) between elements. Developers can set line-height only on a per “box” basis, so keep line height and paragraph spacing consistent at least within the text block, if not site-wide. Never vary the space between paragraphs in a single text block.

Watch for nuances in the fonts. For instance, one of our clients used a font that had no lowercase letters — or so the designer thought. In fact, the lowercase letters were just smaller versions of the uppercase letters, and this caused discrepancies between the apparent size of the font on the site.

These are just a few examples of things we’ve seen our design partners do which were hard to code. Of course exceptions can always be made if it’s an important part of the aesthetic or charm of the site. The important part is to understand the subtle design choices that can make a simple 10 minute style rule into a 3 hour challenge.


Have a question or something to contribute? Let us know in the comments! We’re always interested in hearing from designers and developers about elements you’ve had trouble communicating, details that are tricky or confusing to code, and other sticking points you’ve encountered on a project. The better we get at explaining these things to each other effectively, the more success designers and developers will have bringing their shared vision to life.

Share this post: