Website Design Process

Originally posted some time in 2005, updated 2013

My general approach to web projects on either a personal or team level is to

• examine project requirements
• analyse these requirements
• estimate timescales
• design a solution
• and implement the solution.

Testing Feedback

At every stage, feedback and testing. This means both referring back to research and analysis documentation (emails, tracking systems, any existing codebase) as well as testing prototypes with either clients or colleagues and potential users.

This feedback

• helps prevent project scope creep, and
• helps maintain communication between all people involved

Process?

We aim to create a web sites that are usable. This means that users can find the information they want or achieve what they had intended to. This may seem obvious, but once you’re at the point of implementing a solution that can be lost.

Requirements

Site design is started by working with the client and ideally potential end-users in analysing the requirements for the site - this is the case for even a one page site. Additionally, I would recommend that all developers sit in on user-testing of any current site. Watching people act at odds to functionality that is ‘obvious to use’ sticks with developers at the point they’re deep in code.

What does the site aim to acheive? Who does the client intend as end users? Who are its likely end-users? What do they aim to acheive from the site?

Answering these questions, you begin to get a better idea of the focus of the design process.

To establish an information architecture for the website, you will need to analyse the existing content on the website, or within the organisation.

This, together with the user research will help create a taxonomy (classification) of the content and, from that, a navigational schema, and maybe some broad ideas of the layout of the navigation.

Most sites, even small websites, will have a mountain of content, or potential content. This will either be on an existing website, or within the organisation, or, even, with the users.

The job of analysis is to work through this information and potential information to create a taxonomy or classification of it.

Information Architecture

The Information Architecture is essentially a text based description of what the content is about and how it may be classified.

This may start with an audit of an existing site, including complete sitemaps.

User research should highlight, or intimate what users would like from the website, and the ways in which they access information.

These together should reveal a new navigational schema and possibly a form for the website pages. It may well show how the website will work.

The design of a website isn’t simply ‘what looks good’. A website is a series of interactions leading to a result: finding something out, buying an item, signing up to a newsletter.

As a result what is being designed is a system, a product or an application, so its design needs to arise from how these goals can be most easily acheived by users.

The website’s final layout and the user’s movement through the website are results of the design process, not just by-products of the ‘look and feel’.

Methods used for Design

A website is more like a usable object than a flat brochure, even if marketing is the intended purpose.

As such care needs to be taken in designing ‘how it works’. We’ve already looked at the informational structure of a website, this will suggest how someone might navigate through the site to achieve their goals. These goals are indicated by user and organisational research.

From this we can construct a wireframe prototype. I usually do this in HTML (being a web developer), but it could as easily be done using pen and sheets of paper.

Wireframes

Wireframes aren’t, as some people believe, hierarchical ‘family tree’ style sitemaps. They are an interactive demonstration of what a site will do, not what it will look like or how it will work will work.

Each page shows the responsibility of a website page or control and what will happen in different situations, for example, on a form, what will happen if it is completed and submitted, or submitted incomplete.

People using a website are likely to become very easily visually confused. Each page needs to have attention paid to how user and site goals can be acheived through layout alone.

People have different visual fixation patterns depending on the content of a web page. Designing the layout of a page can focus users on achieving what they would like from a website.

One method of prototyping is to lay out a site using blank boxes, indicating the location of images, navigations and text.

Moving on

Once you have designed what your website will do and how it will be layed out, you have a clear set of instructions for how the site will work. Before that takes place it is very much worth testing these prototypes with end-users.

The final design step is the look and feel of the site. It’s important that a balance is maintained between the functionality of the site and its usability and the end look. The Information Architecture will have been tested and finalised. From this, the complete site can be built, there are, however, a few more finalisation steps within the design.

The Product of the Design Process

There should be a wireframe prototype, a sitemap (which can be quite broad - this article describes the depth protyping can be taken), a navigational schema and some flat designs, a series of templates can built to W3C standards.

Content

Ideally, any content is optimised for legibility and readability on the web as in this Jakob Nielsen article.

Practically, this means recognising that content for the web is less-easily read than content for print.

• Web users do not read articles whole, but skip from section to section.
• It aids usability to highlight key passages and summarise key points.

Templates

The site’s pages will have been mocked-up from the grey-box prototypes in, for example, Photoshop or Fireworks. These pages then need to be laid out using XHTML/CSS.

The XHTML and CSS should be separate - the XHTML should be able to stand on its own as a working page. The CSS can be used to alter the layout radically, changing the order, conditionally changing the context of the whole page.

Build

This set of blueprints allows the developer to build the site, with no ambiguity as to how the site will work ‘in practice’.

The vast majority of the work now needs to be carried out, with feedback and discussion between the client, designers and developer.

You may not keep everyone happy, or have created the most universal website in the world, but if the design process has been carried out effectively, you’ll have a usable and extensible site, that has acheived the goals specified in the site requirements.