Authored by Primate

A rather awesome, informative
and witty blog about all things web

Web design for print designers: an introduction

ABC plastic letters

If only the Internet was as easy as ABC.

A friend of mine who’s just made the jump from print to digital recently asked for some advice on how to adapt to the new world and thus gave me the idea to share my thoughts here. It may be a little late – sorry Ida! – but hopefully it may benefit other curious print designers with little previous knowledge of the web.

First off, this blog post is meant to give a few general pointers to fresh web designers and is purely based on my own experience. I will not go into detail about build techniques, browser discussions, WC3 specifications or grid systems. Nor will I offer opinions on when to use ems or rems, how best to handle retina images or whether Jakob Nielsen’s usability advice is outdated – you’ll get to that soon enough!

What I will do is offer my humble advice on the differences between designing for print and designing for web. Though the problem-solving part of it is constant, the different media and tools require a different mindset.

Oh, and the nature of this post means the following is fairly basic, so if you’re already familiar with designing for the web you may find it a tad patronising. But by all means, read on.


It’s not my intention to start a debate concerning a universal definition of the phrase “web designer”, however for the purposes of this post it is useful to make a distinction between two different approaches to our profession. Let’s call them the one man band and the team player. As the name infers, the one man band is someone who not only designs the web site but also writes its code. The team player, on the other hand, is concerned with design only and relies on other people to do most of the coding.

The advice in this post is aimed mainly at the latter approach, and I shall not attempt to teach anyone how to become a front-end developer. Even so, all web designers will benefit from developing a basic understanding of front-end code, at least HTML and CSS.

Hyper Text Markup Language and Cascading Style Sheets are what define the layout and visual make-up of a web site and generally constitutes what is called front-end code. If you want to design for web you need to get a basic understanding of both. In short, HTML is concerned with the hierarchy and structure – the what and where – of the elements on your web site whereas CSS defines their style and behaviour – the how. So what do HTML and CSS look like and how do they relate?

I have found no better introduction to HTML than this video on Don’t fear the internet which humorously explains how content is structured using fake HTML tags (here’s a list of the real ones), and I thoroughly recommend you watch it now. In any case here’s a less entertaining example of HTML at it’s most basic level:


In this example, “Tada!” is preceded and followed by HTML tags (those brackety things) – the first being an opening tag and the second one a closing tag (identified with the inclusion of a “/”). The “h1″ part of the tag tells the browser to treat – and style – “Tada!” like a header. We can now apply some styles to the h1 tag using CSS:

h1 {
  font-family: Georgia; font-size: 30px;

CSS is really quite simple and works much in the same way as character or paragraph styles in inDesign. All we have to do is identify the element to be styled (h1) and add some style declarations to it (everything inside the curly brackets). The browser will subsequently apply those styles to any content surrounded by tags in the HTML and “Tada!” will be rendered using the font Georgia at a font size of 30px, like so:


Simple, right?

Browser tools

Real-world HTML and CSS is obviously a little more complicated than my examples – there are hundreds of different HTML tags and CSS properties to keep track of – and it can seem a daunting task to memorise it all. Luckily you don’t have to, as there’s an easy way to begin exploring without writing your own code: browser tools.

Presuming you’re using Chrome (if not, install it now), simply right click any element – for example this paragraph – on a web page and select “inspect element”. Two panels should appear at the bottom of your browser. The panel to the left will contain the HTML of this page and the element you originally clicked on will be highlighted. Now look at the panel to the right – it will contain the CSS applied to the selected element. You can click to edit any of the CSS properties in this panel to see an instant preview of your changes. Go ahead, try it!

For a quick visual walkthrough of the browser tools, see this excellent video (once again courtesy of Don’t Fear the Internet).


HTML and CSS, usually referred to as front-end, concern the visual side of a web site. Ruby, PHP, .net – whatever programming language one might fancy – constitute the back-end related to functionality and are, generally, outside of the responsibilities of designers. But there’s a crossover between the front-end and development languages, namely JavaScript, and you’ll want to know about it.

Since the relative death of Flash, JavaScript is the magic that makes your slideshows slide, your tabs tab and your accordions… well, open and close. Theres a lot more to it than that, of course, but in the context of design JavaScript can be described as a sort of hybrid between form and function, bringing your interface to life whilst taking some of the load off the back-end in terms of functionality. If you’re a team player you’re likely to leave the JavaScript to others, however it’s worth learning which interface elements require JS and which don’t (trust me – your coding colleagues will appreciate it).

Having some basic knowledge of JS libraries such as jQuery will give you an edge in assessing the build scope of your latest experiment, however if I’ve learned anything it is that JS can be a time-sink of incredible proportions. What seems simple from a design point of view can often be a massive pain to implement – remaining flexible is key.

Photoshop, Fireworks and Reflow

Good old Photoshop. How did a software designed for touching up images ever end up being the defacto tool for drawing user interface elements and web sites? Personally I think it has to do with accuracy. As long as the web’s output is defined in pixels, it makes sense to work with pixels when creating the input (at least when it comes to photography, illustration and other graphics), and Photoshop is the only tool in Adobe’s drawer that lets you manipulate them accurately – perhaps with the exception of Fireworks.

Photoshop is by no means perfect – many people will recommend other tools, including the browser, and I recommend you as many you feel comfortable with – but it has a few trick up its sleeve. Layer effects, for example. Layer effects lets you apply adjustable styles, such as colour overlays, shadows, glows, gradients and strokes, to any layer (or layer group, provided you’re working on PS6) and are instrumental to achieving consistency across elements.

Speaking of layers, get used to them. Easily the single most time-consuming ‘feature’ of PS, the sheer volume of layers that accumulate in big project files (I normally don’t hit four digit numbers but hundreds is common) creates a daunting barrier to entry for designers used to the relatively flat environments of inDesign and illustrator. The remedy is, unsurprisingly, to stay organised and naming, grouping and colouring your layers make navigation and maintenance completely manageable.

Another way to streamline your workflow is to memorise the keyboard shortcuts for your most common tools and functions. I’ve got my “v”, “m”, “a”, “p” and “f” down (to name a few), and so should you. And if you want to get even more efficient try recording your most frequent procedures as actions. They require a little bit of fiddling around to begin with, but once you’ve identified how to make them work for you they’re a real timesaver.

I could write a whole article solely on PS efficiency, so think I’ll stop here. But seriously, at least for the time being, PS is your friend. Get to know her well.

Note: At the time of publishing this, I’m reviewing Adobe’s preview version of Edge Reflow – a responsive design tool that promises a lot in terms of fluid layouts for those of us who still aren’t designing in the browser. I really recommend you check it out – not as a replacement of photoshop, but as an invaluable addition to your toolbox.

Adopt a flexible approach

Did you notice how I said “draw user interface elements and web sites” earlier? Well, that’s exactly what we’re doing when using Photoshop, and as much as it’s a great tool for creating such drawings, it will always be inferior to the real thing: code. Web sites aren’t static pictures, they are lines upon lines of code, defining your grid, type, colours, layout; everything. And, surprise, surprise, a lot can change when our drawings are made to work across a plethora of browsers and devices.

Unlike in the print world, where static layouts are produced for a finite amount of predefined content, things are never straight forward online. Ever had that shade of grey come out slightly off in print? Try achieving colour consistency across every display connected to the Internet (hint: you can’t). Worried the finer detail of your typography won’t work well on uncoated stock? Wait until you’ve seen it rendered on a Windows machine using a 10 year old browser.

My advice is this: redefine your idea of perfection and make your layouts accommodating. If something just fits inside an element, chances are it will break somewhere down the line. If your headlines have to fit on one line, you can be damn sure someone will force it onto two. Considering how much content is entered post-design (sometimes by a client from across the world), it’s up to you to ensure the design makes allowances for less-than-ideal content scenarios.

Responsive web design

Coined by Ethan Marcotte back in 2010 and tipped to go fully mainstream this year, responsive web design puts the notion of flexible layouts in a whole new light. In essence, we’re talking about designs that change depending on the viewport; be it a smart phone, a tablet, a TV or a desktop monitor. Designing for all devices, present and future, is, to put it mildly, challenging – not least because it takes longer and often costs more (or does it?) – but once you embrace the tenets of responsive principles it’s difficult to see how one could possibly avoid it.

Responsive web design is far too vast a topic to cover in a couple of paragraphs and I won’t go on about it at length, but I urge you to explore it on your own. Luckily there are plenty of resources out there; a lot of very talented people have shared a lot of very incredible contributions for others to learn from.


Although significant, usability in print design is slightly less of a minefield than it is on the web. A well designed magazine allows the user to open it (!), quickly scan the contents, navigate to the desired page using clearly identifiable page numbers and read the content without thumbs getting in the way or text disappearing into the gutter. And that’s pretty much it.

The online equivalent have no physical gutters to worry about, but plenty of other pitfalls. Are links obviously clickable? Is the content easy to scan? What happens when I hover over the menu? How does the interface communicate that the user has done something wrong (or right)?

Getting from A to B on a web site can be quite the challenge if the usability is poor and where magazine readers might persevere, web users are more likely to close the tab and go somewhere else. So keep on top of your usability and constantly ask “is this clear to someone who have never seen this site before”? If the answer isn’t a resounding yes there’s probably room for improvement.


Designing for the web is an incredibly young phenomenon, relatively speaking, and one of the best things about it is that no-one yet knows exactly how to do it right. Yet there are plenty of amazing people trying to figure it out, and they all willingly share the fruits of their experiments. I’ll leave you with a short, very incomplete, list of resources, blogs and talented people that I’ve learned a lot from during the short time I’ve worked on the web. Enjoy!

Some resources

Typecast – A must-try browser-based typography tool for all web designers.
CSS hat – A Photoshop plugin that converts your layer styles into CSS. Very handy.
Modular grid pattern – Quick grids in photoshop? Yes please!
Guide Guide – More Photoshop grids. Particularly powerful when used with the Modular Grid plugin above.
Gridset – Flexible CSS grids by Mark Boulton Design. Well worth a look.
Typekit – Web fonts galore. There are more font servers out there, but this is our preferred option.

Some things to read

Smashing magazine – The one and only. Lots of useful resources for the budding web designer.
Don’t make me thinkSteve Krug’s usability canon. Read it.
Ordering disorder – A very useful introduction to grids on the web (by Khoi Vinh)
A List Apart – Freshly redesigned, this magazine should be on every web designer’s reading list.
Design is a Job – Design and general business advice from the internet’s nicest jerk – Mike Monteiro
Responsive Web Design – By the eminent Ethan Marcotte. It all started here.
Don’t fear the internet – Previously referenced, this is a very good place to start if you’re an absolute beginner.
Information architects – Famed for a simple, typographic approach to design Information Architects are on our list of design legends.
The personal disquiet of Mark Boulton – self explanatory really. Mark Boulton is also on said list of legends.
Trent Walton – Speaking of legends, Trent Walton shows us all what happens when designers really know the magic of CSS and HTML.
Elliot Jay Stocks – Emerging rockstar of the internet, Elliot will one day save the world using typography. Maybe.

Oh, and follow @RWD on twitter. Responsive gold.

PS. To all of you who are not on this list, don’t worry – you’re still awesome. If I listed every single amazing resource and/or person on the internet I would be here for years.

Image credit: Marina Shemesh

If you liked this article then why not subscribe to our RSS feed.

Author: Espen Brunborg

Espen can easily ruin conversations with questions about chimneys.


Leave a Reply