Don’t start with a page template

One of the most important lessons I’ve learned in web design is this: don’t start with a page template. Focussing your initial design effort (and front-end coding) on a homepage or indeed any other kind of layout template is not the way to get the best results (unless you really are just designing a tiny one page site). In recent years responsive design has reinforced this philosophy but even for fixed-width websites the same applies.

Start by specifying a system. This system should grow as part of the branding (or visual identity) to form a visual language. You can use style tiles as a way to explore the character and tone of a design – and to facilitate client involvement in the process. Then, once a visual treatment has been agreed, the visual language can be fleshed out further, making the transition directly into a set of base CSS styles which are applied to a comprehensive range of types of content and UI elements.

What we are basically producing here is a style guide. As well as the range of basic HTML elements (buttons, forms, headings, lists, and so on) it pays at this stage to include any more complex or customised UI elements that you are likely to need. These might include tabs, panels, icons, error messages, navigation, calendars, and so on. Existing frameworks like Bootstrap are good places to go for inspiration to remind you of the types of elements you might need. You might also have a set of wireframes to work from. It is worth putting a lot of effort into these base styles so that they work well across your target browsers and use contexts. They then become the building blocks of your UI, and you can pass these files to a backend development team.


A better way to design

Large web projects are continually growing – having new screens added to them, bits changed here and there – and the best way to ensure a consistent visual experience is to create a system. Once you have such a visual system it becomes easy to add new layouts because you already know the ‘rules’ for constructing each building block. Of course this has been true of graphic design forever: book design needs a system in just the same way. But websites grow and change much quicker than books; and the emergence of responsive design means that even a single page of content may morph into several different layouts depending on the kind of device you view it on. In this situation thinking of a website in terms of a set of page layouts really doesn’t make much sense anymore.

Of course, while you are designing your visual language you do have to consider a range of specific layouts too, to make sure that the elements you are designing will cover the type of screens you’re going to need, and to see some examples of how things hang together. In practice I may start out with a style guide, then create some actual layouts and move back to work on the style guide to tweak the system. In addition, you usually will need to hand over at least some specific templates alongside the base styles, to show the headers and footers and how the grid and modules work, etc. So page templates are still important; just not the primary focus in the initial stages.

A better way to code CSS

There is another big win to be had from the style guide approach: you will end up writing much better CSS. It is far easier to construct a neat ‘object-oriented’ system of styles if you start by considering a good range of element types up front. It helps to focus on a sensible system of sub-classes while each is fresh in your mind, and it is much easier to tweak your class structure when you only have one of each element, rather than having to trawl back through several templates making multiple markup changes each time. Approaches like Jonathan Snook’s excellent SMACSS have helped me to improve the maintainability of my CSS; but it is far more practical to pursue an approach like this when working from a base set of elements, rather than building a site one layout template at a time.

Also, in my experience developers love having a set of good-looking base styles. It means that whatever they create at least looks right at a fundamental level. There is not always a designer on-hand and this way you can keep things pretty neat and tidy no matter who is working on the site.

A better way to prototype?

A lot of UX designers are starting to prototype and test directly in code. While I still tend to work with a sketchbook and then Axure or Omnigraffle most of the time, I can see strong advantages to the HTML prototyping approach, especially when working with and testing responsive web pages. It strikes me that rather than the traditional approach of prototyping with generic ‘wireframe’-type styles, maybe the brand and visual language could be completed first, and then those styles used for prototyping and testing. Of course you may not know all the different types of widget you’re going to need before the detailed interaction design is completed, but at least the basic, common styles could be put in place. I’ve not actually tried this yet, but it’s something I’d be keen to explore.