Advice for Web Designers (part 001)


It's not about how to make your designs look, exactly, more how to get them set up for production.  Managing layers, file names, colors, fonts/sizing, etc. I'm sure there will be more as time goes on and I run into other items to point out, so this is just part one.  Some information is going to be concrete5 specific, but most of it should apply to any web development project.


I've worked with a lot of designers, and all of them have different ways of doing things. I don't really do design myself, but ever since my days in print production, I've been working with files from different designers of all different skill levels. From industry experts with years of experience in huge firms with extremely defined style guides all the way to students bringing their first digital files to the printer. I often got to help with those people to be able to make the next jobs they submitted go faster. 

But it was simple stuff - missing fonts, not linking images, picking different versions of the same spot color name.  Things in web development are a lot more complicated. A quality developer will be able to turn almost anything you give them into a nice website, but making sure that your design files are set up properly at the beginning can save a lot of time and money as you go live.

The Simple Stuff for Web

I'm assuming that if you're reading this, you're probably using something like Photoshop for creating comps.  Then those comps are exported out to jpg, approved by a client, then sent to a developer who turns them from PSD into an interactive web application.  This seems to be the pretty standard work flow that I've seen over several shops and dozens of different designers.

So, what are the biggest things that people do that cause errors and delays in production?  There are a ton, and here they are in pretty much no particular order.

Be Very Careful With Your Fonts

Don't Use Points
Seriously, this will cause all sorts of problems. A point is not a pixel. You should probably just start out with pixels in your Photoshop file.  When you refer to font sizes in markups and emails, use pixels.

Don't Use Decimal Points In Type Units
This might seem like common sense, but oddly it's not. There are only discrete pixels on a computer screen, so specify your sizes in whole numbers.

Be Aware of What Web Fonts You Are Using
For a print design, you can use a lot of different fonts within the same family for a design with really no real consequences. Every so often, it can cause extra time in rendering a plate or processing a VDP run, but there's no real drawback. 

For the web, you have to think about how the fonts are going to be loaded. You can specify the font weight either as a number (100, 300, 500, 1000, etc, in increments of 100) or as "lighter, normal, bold, bolder."  But the thing is, some fonts only come in families where each font is a separate font file. So you have to load all of them, rather than just one. 

There are also limitations with different font platforms. Google web fonts will flicker for a moment on load before replacement, which means that they really aren't great for large sections of body copy. TypeKit does not have this limitation, but costs money. Do some research on different platforms before you decide on an actual font. 

Don't Use Faux Styles
This is something that a lot of people do. The character palette in Photoshop has a little menu where you can apply 'faux bold' or 'faux italic' to your fonts.  DO NOT DO THIS.  Seriously. When the developer person comes to your file, they are going to be selecting the font and copying the values from the palette to create a css file. Often, the developer could be running their Photoshop within a virtual machine with a limited amount of video memory. So it's not always clear if a font is bold or not. If the panel doesn't say it's bold, the css file won't be set to bold, and then when you go to approve the final site, you'll be like 'hey, it's not bold!' 

It's an easy mistake to make, and one that I see all the time. It's certainly avoidable on the developer's side as well, they could check every instance to make sure it's not faux bold, but that's a lot of clicking. Why not just set it to actual bold in the font panel?  If the font doesn't have bold, then maybe it's not a font that you should be using on the web?

Remember What Headings and Elements Are Available
Often, you see files with 'subhead 1, subhead 2' etc sometimes defined in the main content area.  But there is no definition in the sidebars or headers. And actually, the headers expressed from a DOM / SEO standpoint are actually more accurately expressed with headings 3 and 4.  Or people will only define 1 & 2, but then for 3, 4, 5, etc there are things throughout the doc that may or may not be the same, or could just be different colors of the same headers already defined, or just hitting bold on the regular paragraph font. It can take a long time to figure out what, exactly should be used where.

You can avoid this by making a typography layer in your Photoshop file and explicitly defining everything. Remember, that you will most likely NOT have the final say of the html tags used on the site. Most modern content management systems offer quite sophisticated rich html editors, which allow the site owner to plug in whatever content they like. While every contingency cannot be planned for (yes, sometimes they do put in 72px pink comic sans inside a blink tag) you can help by defining more than just the first couple heading styles.  Remember about lists (multiple levels, too!) and tables. Think about images, both with and without captions.

Another option here is to work with your developer to define exactly what tags will be allowed in the WYSIWYG editors. It is customizable in most quality content management systems. It may be a bit more dev time, but it ensures that you won't be getting calls from the client later wondering why it looks funny, or people asking why the site you linked from your portfolio looks totally broken.  

For some content management systems, you can also define custom styles for the editor. We often do 'blue' or 'green,' 'success,' 'small,' etc in TinyMCE for our concrete5 sites. These can be used to modify existing tags, but you should use them with caution.  They don't always apply properly, sometimes creating a span inside of the intended tag, or sometimes targeting the parent instead of the intended. But for applying a color or a carat or whatever, they can be useful. 

Once you are comfortable with what the basic elements are, you should start thinking about them in terms of how you want the DOM structured for SEO. Sure, you can probably trust that a developer will do this for you, but really, a lot of them don't. You might have a sidebar callout that should have h3, h4, img, and a p tag inside of an article tag. The developer might not know they're supposed to be headings (or care, if it's not specified) and instead give you a bunch of paragraphs inside of a div, or spans with breaks. You really don't know.

Since a lot of mocks are created with Lorem Ipsum text, it's easy to simply put a simple "h3." or "h4." in front of the element outside of the main content area so that they know what tag to use. This will help you out a lot with SEO and forward compatiblity, and with accessibility.

You don't need to worry about matching the font sizes or colors or anything to do this, the tags can be reused in different areas with different styles without any issues. It will create a bit simpler and smaller CSS documents if they share some base characteristics, and the code will likely be more maintainable and updatable in future redesigns. But that's not a 100% rule, and it isn't something that is required by any means.

In concrete5, you can set up the tinyMCE editor to use a typography.css file in your theme's root. Not every editor uses it (this might be fixed in 5.6+) but most do, and a competent developer should be able to standardize the fonts in all editors site wide.  It's important to remember that it only works for the currently active theme. Modifications to elements outside of the main content area that have a tinyMCE editor will use the styles from the main area, not the overridden styles from main.css or the block's individual css file. There's no way around this currently, but future releases will have a different editor that addresses this.

Use Layer Blending / Masks and Styles Carefully

Again, this kind of seems like something that you don't need to point out, but I'd say at least 50-75% of the files I see have problems in this area. Often from people that are highly skilled in web design and have been doing it for years and years. 

Repeat After Me : The Only Opacity Mode Is Normal Mode
I don't know why people do this. In CSS, you don't get to do multiply.  Not for shadows, not for elements, not for anything. Keep it with 'normal' mode. This will make things easier on the developer and ensure that the final output actually matches your design. Otherwise is a fair amount of guesswork and approximation for the developer, and it will never quite match 100%.

Put The Stroke On The Outside
When you use the border in the layer styles palette, you have options for setting it for inside, center or outside. Technically, you can do both inside or outside, but don't do center. This especially applies to vector layers. If you are thinking that your box is 300px by 50px, but the border is set to center (the default) it will end up being about 301x51, which looks weird. If you put it inside, you'll be drawing it 300x50, but if the dev enters 300x50 and then 1px border, it will end up 302x52. It really isn't a huge deal, but it does make things a lot simpler when slicing out. 

Be Careful With Layer Masks
These are fine in theory, especially if you are merging in a large image and need to crop it. But if you are trying to do an irregular cutout, you have to be aware of what the elements underneath it are going to be. In order to do that kind of mask with an image mask in css, you have to have an image that has a transparent center and an opaque outer, then position the actual photo underneath that. If you are expecting to cut out an irregular image that appears 'on top' of a pattern or gradient, beware that it might not actually be possible.

There are probalby some exceptions with css3, but I'm not sure how to do them, and I don't think they're well supported yet (early 2013) so I'm not sure if they could actually work.

Keep Your Layers Organized

This is really pretty important. When you're designing, you know what everything is, you can just throw it in, copy, paste, etc as much as you want. But when you bring them to another person for production, it's a very good idea to keep them organized. 

That doesn't just mean "Home Page", "Interior Page", and "Blog Post" and then a bunch of layers underneath that. You should do a lot more detail than that. When a developer looks at the file, they're going to be trying to figure out what elements are where, and they're often going to need to turn layers on and off in order to properly export transparent PNGs and GIFs. 

Your Layer Sub-Folders Suggest Your Document Structure

Think about your document and your layers semantically. Group the elements by where they show up in the design. Header elements should all be together, and consistent across different layers if they are not on a separate 'common' layer. The same with footers and sidebars.

And then within those layers, group again, and again. Do you have a secondary navigation in the sidebar? Create a sub folder for it, so that the whole thing can easily be turned off and on, and copied between layers.

You should also be thinking of these in terms of what kind of markup they will generate. I'm not saying that you should become an HTML/CSS guru by any means, but you should kind of think about learning the basics.

Your menus will more likely than not be unordered lists.  So when you make a menu, don't do a big text block with a bunch of lines, then position elements next to them to complete. Or for horizontal navs, don't just add spaces between the words. Instead, make discrete elements for each one and copy them. You don't have to, but it makes things a lot clearer. A program like Adobe Fireworks is really great for this, it has a 'button' tool which you can use to quickly add them to documents.

The things in your sidebar or footer, callouts, etc will most likely be block level divs. They will flow like big squares. So watch how margins vertically look. Make sure that images aren't arbitrarily extending up out of the box created by the text alongside them, etc.

The fact is, naming everything semantically and keeping them organized in sub folders that correlate to elements will have a ton of benefits.

Not only will it be quicker for the developer to split the file out, it will help with communication. If you call a layer in the sidebar 'testimonial' that has an image, title, text and link, the dev knows right when they look at it what it is and some idea of what information to put into the editing interface. The naming of the divs now can be done to match this feature, and when you talk about it with them later on in review / testing, you will both know immediately what element is being discussed. 

If you just have a bunch of text layers and images on random layers in the sidebar, it may not be clear that it's the Testimonial you're talking about and not the Latest Product, or whatever. 


Doing these things won't automatically make you a better designer. It may not actually make sense on every project, especially little things. But if you start paying attention to the details when you create your Photoshop documents, it will lead to better websites. And probably save you time and money. 

This is certainly going to be the first in a series of many, I think. I have a lot of ideas, and there are so many details to think about as you set up things to send off to a web development shop. Or even to your developer down the hall. I didn't even touch on responsive considerations, proper use of grid systems, how to properly use a mask that makes it look like it's in a web browser for your email comps.  Or file naming conventions to ensure that you are always sending the most recent versions of files. Or what you need to do when defining background tiles. Proper measurement and aliasing?  The list goes on and on and on.

It won't all be thrashing on designers. I'll try to put together some tips for developers, too, but those are almost certainly going to be concrete5 specific. More along the lines of: "If you see this in code you get from someone who claims to know how to use concrete5, stop dealing with them because they're a total idiot and will cause you more damage than good in the long run, no matter how cheap they are willing to work." 

If people like these, I'll try to start doing more research / background checking so you can get links to sites with more detail or examples, create print screens and sample code, etc.  Please let me know if you want more of these in the comments.  I'm kind of lazy, so taking another 4-8 hours to do all of that after spending 2-3 hours writing the post seems like a lot of effort. ;)