Ford Interactive

Great graphic design and great typography will always be great graphic design and great typography no matter what the medium. And print design and web design are two mediums which have a great deal in common. But there are some differences in the mediums. Switching from print design to web design can reveal some limitations and constraints along with some new freedoms

I’ve worked almost exclusively in the field of web design (and development) and very little in print design. Not much as someone who “does design” but very heavily as someone who “implements designs” with (X)HTML, CSS and JavaScript. Over the years, I’ve seen patterns emerge with print designers doing web design. Little web design details that are often overlooked that don’t usually apply to print design.

I’d like to discuss some of the mistakes and oversights that seem to be common with print designers switching to web design. My intention is not to be rude or discouraging, but to be informative and provide a sort of “checklist” of common mistakes for print designers transitioning to web design and for the people like me who implement their designs. A lot (probably most) of the really amazing web designers came from a graphic design and/or print design before they did web design (Jason Santa Maria is a shining example). So with a little time and patience, I think any talented print designer can become a great web designer.

Resolution

I have to mention this first because I’ve seen it a lot, and it’s pretty important. The web is a 72 pixels per inch world. Not 96. Not 300. Not 600. Seventy-two.

Typography

A lot of print designers aren’t aware of the limited web safe font palette. Luckily you can use techniques like sIFR, FLIR, or cufon to get any font you want, but that’s best suited for headlines or small bits of text and not really intended for paragraphs of body copy. You should still stick to web safe fonts for body copy. (Edit – Nov. 17 2009 - Since writing this, several services have emerged for serving up custom typefaces using the @font-face CSS rule: Typotheque Web Font Service, Typekit, and Kernest.. Jonathan Snook has also written 2 interesting articles of a more DIY nature: Screencast: Converting OTF or TTF to EOT and Becoming a Font Embedding Master which build on Paul Irish’s Bulletproof @font-face syntax.)

Other typography related print designer faux pas I’ve come across are using Photoshop’s faux bold and/or faux italic. This can’t be done on the web – use the regular font-style controls. Another is relying on paragraph hyphenation – web browsers don’t support hyphenation (possible workaround). Also be very careful in using justified text. It can be done, but the results aren’t always great (Jon Tan‘s site is one that does seem to pull off justified text quite well. His site is also worth mentioning for the amazing design, layout and typography as well as well written articles about design, layout, and typography ). Another thing to watch out for is messing with vertical and/or horizontal scale. There is a “font-stretch” CSS property, but has little or no support at the moment.

Another font flub I see is with font sizes. Or more specifically – half-sizes. Browsers can only display in increments of 1. So 13.5pt isn’t going to work. Round it up or down to the nearest whole number. Also, some print designers will use very small font sizes like 10 or 11 pixels for body copy. This is pretty hard to read on the web – especially for people with less than perfect vision.

Viewport

A lot of print designers neglect to account for the resizable nature of the browser viewport – probably because they’re used to a sheet of paper always being a specific size. They’ll often not spec what happens (with backgrounds, borders, etc) when the view port is wider than the provided design or if the design is to be centered or aligned left or right in the browser. Sometimes they also won’t account for the bottom of the page if the content doesn’t fill up the entire height of the view port.

Sometimes they may have a spotlight or some other type of effect in the background that clips off in the provided design, but you’ll need that background to resolve to some kind of neutral and/or tile-able pattern when the view port is larger vertically and/or horizontally than the provided design.

Think of the web as having a nearly infinite bleed.

Vertical Pixel Precision and Vertical Grids

You can do a lot of things with CSS, but sometimes there are elements in a design that rely too much on text filling up a precise vertical height. Usually this is in some sort of a columnar/grid context. But invariably, the marketing/communication folks will change that text 12 times before the site goes live. The vertical height of the actual text columns may not end up being the same and the integrity of the design could be compromised. This happens pretty easily with CMS sites.

Sometimes you’ll have an image next to some summary text and the text will be precisely the same height as the image. But what if that text was longer? Will it wrap around the image or keep a consistent columnar width? Not a big deal, but often not accounted for.

Another print designer tendency is to use specific page heights regardless of content. I can see how this could be a force of habit for a print designer. It is possible to implement precise height pages on the web, but it’s better to plan for content causing the page to stretch vertically and let go of the notion of precise vertical heights.

(Non) Interaction

A very common oversight is neglecting to specify link rollover and or “on” state colors/treatments. This can occasionally slip the minds of even very experienced web designers, but much more so with print designers transitioning to web design. From main navigation all the way down to body copy, it’s good to spec link states. You can put the rollover states in a hidden layer or layer group with “rollover” in the layer name so the person implementing the design knows what it’s for.

PSD Layers

Get rid of the unused stuff

Cutting out the cruft is very considerate. If there is a layer that’s not used in the design, then that layer doesn’t need to be in the delivered PSD. Unused layers just make the file size unnecessarily larger and make working with the file a little more confusing. Any hidden layers or layer groups that are in the delivered file should actually serve some purpose such as being rollover states or notes for the developer implementing the design. I don’t need to see all of the super high-res watermarked istockphoto images that you didn’t use.

Group it. Name it

This is not common (and probably has more to do with overall experience rather than preferred design medium), but I’ve seen some PSDs that don’t use layer groups or even layer names – this is a real pain to deal with! Give every layer and layer group a meaningful name – I don’t know what the hell “layer 47″ is, but I can probably figure out what “divider lines” or “search box” is.

Miscellaneous

• Web safe colors: some print designers will try to stick to web safe colors. This is an outdated concept (for most audiences) and we don’t need to worry about web safe colors anymore thankfully.
• Fancy Forms: Some form elements – mostly select boxes (dropdowns), checkboxes, and radio buttons are a pain to style consistently in all the major browsers. There are some javascript workarounds, so check with your developer before going too crazy.

I think that about covers the most common mistakes I’ve encountered with design files delivered by print designers switching over to web design. So if you’re a print designer transitioning to web design, or if you’re someone who is working with a designer in that position, these are probably the most common things to watch out for.

This is also a very “blue-collar” list coming from the perspective of an XHTML/CSS coder who’s job it is to implement designs.  I’ve been exposed to a lot of great design by working with a lot of incredibly talented designers, but I do not have the proper design education to truly call myself a designer.  I think there could be another level to this discussion which I am not qualified to delve into; but a more theoretical design discussion about the theories and approaches to print design versus the theories and approaches to web design. Also, I have not touched the areas of usability or accessibility which become much more important on the web.

Updates & Further Reading

August 29, 2008 – Friend and fellow front-end developer, Mark Aplet, wrote about this very same topic a couple months ago. We cover some of the same ground, but Mark’s well written post covers quite a bit and gets into some finer detail. If you found my post helpful in any way, you’re sure to dig Mark’s.

April 16, 2009 – Jeffrey Zeldman just announced that his book “Taking Your Talent to the Web: A Guide for the Transitioning Designer” is now available for free as a PDF. It was published back in 2001, but still makes relevant points.

Also Smashing Magazine just published an article titled Switch from Print to Web: Where to Start? which has a lot of advice and links to resources.

November 12, 2009 – See also Print to Web Design: Comparative Analogies by Chris Coyier Nov. 12 2009.

March 5, 2011 – See Alex Kendricks post on using Layer Comps in Photoshop.

July 26, 2011 – Very snarky post, but a lot of truth to it: 20 things that drive web developers crazy by Rafael Mumme

You might also be interested in:

• This Way to the Web, Print Designers! by Khoi Vinh, former Design Director for NYTimes.com and author of Ordering Disorder: Grid Principles for Web Design.
• From Print to Web: A design discussion with Dan Rubin – don’t miss the PDF download of his presentation.
• Transitioning from a Print to a Web Designer on thedesigncubicle.
• From Print to Web: Avoiding Common Design Mistakes by Inayaili de León at Web Designer Notebook.
• Don’t Make Me Think: A Common Sense Approach to Web Usability by Steve Krug is a must-read book for every web designer.