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.

3 thoughts on “Don’t start with a page template”

  1. A sensible approach Ben, especially when working on a responsive site. I’ve been trying to work this way with mixed results. In a way it’s very liberating and there is something satisfying about how quickly pages can be put together from the building blocks. Abstracting the site into blocks forces you to rationalise elements into a lean, focused set of styles. At the same time, I’ve found myself having to regularly tweak the style system as I actually implement it on real pages. Also, every now and again you might something that breaks out of the system, otherwise it can just look too modular….

  2. Good points. I also end up tweaking things as I design actual views. I seem to end up designing a number of views in tandem with the style guide. Also, I guess you’re probably right about things becoming too modular, but then there’s nothing to stop you adding a new, unique ‘module’ for a single page if you want to.

    So it’s not a perfect approach. But if you look at the alternative of just designing a discrete collection of templates, there’s no question really…

  3. One thing I have found recently is that a style guide like this doesn’t always work very well as a deliverable in a waterfall-type setup. Without a designer to keep the SG updated, and a very good understanding and buy-in of it from the development team, it can tend to become outdated and ignored fairly quickly. So I think it needs constant work and a carefully planned process to get full benefit.

Leave a Reply

Your email address will not be published. Required fields are marked *

Help me make sure you\'re not a machine * Time limit is exhausted. Please reload the CAPTCHA.