9 Things to Do Before Passing Your Website Mockup off to a Developer

Are you designing a website layout in Photoshop that needs to be coded (by you or someone else)? This is for you!

(Particularly if you’re not the one who’s doing the coding)

1) Organize your layers and keep your mockup clean

I love a PSD with labelled layers and organised groups.

• Name all of your layers. Be concise and descriptive.
• Group related layers together. For example, if you have a button you’ll probably have one layer for the background and one layer for the text. Put those in a group called “Button” (or similar).
• Group section of the site. You might have the entire header area in a group called “Header”, the entire footer in a group called “Footer”, and so on.

2) Mock up every page on the site

If you plan on designing and coding this layout, then you can skip this step. When I design and code my own stuff, I typically just mock up the main layout and replicate the rest directly in the code.

But if you plan on passing the mockup off to a developer, this is important!

If you don’t include certain designs or layouts, then the developer will have to guess how the layout should work. So if you want it to look a specific way, you need to convey that.

3) Stick to a clean grid system

Many layouts are built on some kind of grid. Things will be much easier for you and the developer if you use a grid as a guide when laying out columns, boxes, and other page elements.

4) Don’t use “pt”

Point values (“pt”) are used when preparing a design for print. They’re not meant for web work. W3C highly recommends against using pt for web work:

The so-called absolute units (cm, mm, in, pt and pc) mean the same in CSS as everywhere else, but only if your output device has a high enough resolution. On a laser printer, 1cm should be exactly 1 centimeter. But on low-resolution devices, such as computer screens, CSS doesn’t require that. And indeed, the result tends to be different from one device to another and from one CSS implementation to another. It’s better to reserve these units for high-resolution devices and in particular for printed output. On computer screens and handheld devices, you’ll probably not get what you expect.

There is another reason to avoid absolute units for other uses than print: You look at different screens from different distances. 1cm on a desktop screen looks small. But the same on a mobile phone directly in front of your eyes looks big. It’s better to use relative units, such as em, instead.

[…]

The only place where you could use pt (or cm or in) for setting a font size is in style sheets for print, if you need to be sure the printed font is exactly a certain size. But even there using the default font size is usually better.

W3C Web Style Sheets CSS tips & tricks

5) Don’t use half pixels! (or other fractions)

Half pixels are another nasty one, particularly with font sizes. When I see a font in the mockup is 14.47 pixels, I have to make the judgement call to round up to 15 or down to 14. Sometimes I spend a stupid amount of time stressing over that.

Sure, you can give a font a size of 14.5 pixels and call it a day, but half pixels don’t actually exist. Different browsers will interpret 14.5 pixels differently, and it may not always be what you want or expect. It’s best to just avoid them, as they’re not really intended to be used.

6) Want hover effects? Include examples in the mockup!

I tell the designers I work with that anything not included in their mockup will be left up to my discretion. That often includes things like:

• List element styles
• Styles for different headings (h1 h2 h3 etc.)
• Link hover effects (colour change, underline, etc.)
• Button hover colours

If none of those things are included in the mockup, then I don’t know how you want them to look. So I will either use my discretion or just leave the styles as the defaults (unstyled).

I find that hover effects are easily forgotten. So if you want your developer to add them in the way you want, be sure to include examples!

7) Make a note of any plugin integrations

Here’s a good example: you include social sharing links/buttons in the mockup. When I look at it, these questions all run through my head:

• Am I supposed to code these myself from scratch?
• Is this a specific plugin that you have in mind? Or am I responsible for picking one?
• Will I need to customize this plugin or does the mockup use some default style?

These same questions can then be repeated for other elements of the design, like maybe an “about the author” feature after blog posts, or a custom widget in the sidebar.

Make a list of all plugins

If you have certain plugins in mind to go with the design, write down a list and send them to the developer. That way the developer can install them all on their dev site while coding the theme and can ensure that everything integrates perfectly.

8) Opacity and text do not go well

If you want a coloured box to have some transparency, but all means adjust the opacity. That makes sense and can easily be noticed and achieved by the developer (and use of RGBA).

However, opacity and text/fonts should be avoided. Sure, RGBA can still be used to achieve transparency, but there are a few problems with it:

1. Odds are, you don’t ACTUALLY want the text to be slightly transparent. If that is exactly what you want, then go for it. But usually I find that you were just looking for a quick way to lighten the font colour a little. If that’s the case, adjusting the opacity isn’t what you want—pick a different colour instead.
2. Because of #1 and the idea that you don’t ACTUALLY want it to be transparent, it’s easy for the developer to overlook the opacity since they don’t expect to find it in text. This happens to me all the time. I just edit text to get the font colour and copy it over to the code. Then later, I realize the text colour doesn’t look the same, and that’s when I realize that the opacity of the text layer was reduced to 70%. It’s just super easy to overlook on text!
3. Unless you actually do want semi-transparent text, the idea of resorting to RGBA just feels hacky and unnecessary. Find the colour you’re really looking for rather than adjusting the opacity.

9) Clarify any responsive/mobile requirements

The responsive behaviour is usually left up to my discretion as the developer. If that’s okay with you, great!

But if you want your mobile site to look a certain way then you need to create a separate mockup for it. Things to consider:

• How do you want the mobile navigation to look/function?
• What elements (if any) do you want hidden on mobile?