Let's imagine you've got a new web project in mind but haven't yet appointed a web design team. Most aspects of your business model have been worked out, and you've thought about most of the things your website will need to do. Next, you need to get a couple of web design teams to submit their proposals.
A decent proposal
You may want to draw up a brief before contacting the web design team. Other people will choose to get the ball rolling with a phone call or email. In those cases your potential suppliers might ask you to answer a set of questions, or fill in a Request For Proposal form, which will provide the information they need to judge the project scope. This usually leads to further discussions where all parties can gain a fuller understanding of the project.
The teams will then be in a position to write an outline description of the site; the functionality, pages, hosting requirements and so on. This is the 'initial proposal', and its purpose is to allow you to assess the competing web teams' understanding of your requirements, judge their technical capabilities and - of course - value for money.
Once you've chosen your web team they'll get into detailed discussion with you before moving on to in-depth planning (most of which happens in-house as it is often of a technical nature). They may discuss visual design issues at this stage, but only in broad terms; it's important to concentrate on the functionality of the site at this point. The culmination of this phase is the all-important Project Specification.
This is quite simply the document that defines every aspect of the project. It's a working document which all parties refer and add to during the life of the project:
Programmer: 'Hey, does the user get a confirmation email when they cancel an order?'
Project Leader: 'Look in the Project Spec!'
It includes accurate costs, rather than the 'ballpark' estimate from the initial proposal. Having planned the project out in minute detail your web team will have a much better idea of how long all the individual elements will take. One of the most useful parts of the document is the wireframes. The what? Here, let me explain...
I love wireframes. They're an excellent way to describe a website before it's actually built; something like the storyboards film makers use. On the one hand they allow the client to see just what happens when they press a particular button. On the other, they show the web team's programmers exactly what to build. So you don't end up with a website that does something different to what you had in mind. By approving the Wireframes you're saying 'Yes, that's how I want my site to work. Go build it.' No nasty surprises.
Above: an example wireframe from a recent project.
Sometimes a project is so complex that an additional internal planning stage is required to plan the programming of specific functional elements. It doesn't make for very exciting reading though, so let's move on...
Usability testing 1 - proof of concept
Why test your website? After all, your web team have spent all this time and effort planning it carefully haven't they? Well, it's really about protecting your investment: usability issues discovered after a site is launched can be expensive to fix. Worse still - they may never even be noticed.
This round of testing can be carried out using paper prototypes based on the wireframes that were created earlier. (Which, by the way, makes not only makes the testing cheaper, but makes the Wireframes even more useful!)
The point is to check whether the site can be used, before it's built. It tests users' ability to carry out defined tasks ('can they buy a product?' not: 'do they like the colour?') and any problems found are fixed before moving to next stage.
See our article about Usability Testing for more information.
Notice how your eager web designer hasn't actually 'designed' anything yet? That's because web design is not simply about how it looks, but how it works. (I know, I'm starting to sound like a broken record here!)
You've discussed the look and feel of the site and you may even have provided a corporate style guide for your designers. They will generally follow several design avenues in-house before refining their ideas for presentation. The chosen design is then worked up and signed-off once you're happy with it.
Now they know how the site will look your web team can create the templates that will set the style for the entire site. These should be tested for web standards compliance and accessibility (although most web designers skip this important stage) and checked using the specified web browsers.
Usability testing 2 - proof of design
For this round of testing HTML mock-ups of the site will be used, based on the actual site design. This checks that any problems found in the first test have been rectified, as well as checking that the visual design hasn't 'broken' the concept: does that flashing pink 'buy now' button confuse people?
All this time you will have been beavering away getting all the content together, so that your web team have the raw materials they need to build the site.
Look Ma, I'm actually building the website!
This is where your team get down to the nuts and bolts of building the website; programming pages, functional elements (a shopping cart or user registration for example), installing and setting up databases, turning the content you provided (eg Word files) into web content (eg HTML), optimising graphics and so on.
During this stage is the exciting point where the functionality (how it works) and display (how it looks) come together, and suddenly: you've got a website!
At this stage the site will usually be hosted on a development server where the public can't get their hands on it; your team have got to test it first...
Once your web team are happy with the site you'll be asked to give it a thorough going over, using a checklist to guide you through all the functional elements. This process has to cover all aspects, from how it looks ('are they the correct pictures?') to how it works ('can I buy that product in extra large?').
Along with the planning at the start of the project, testing at the end is arguably the most important part of the whole shooting match, and you should expect your web team to urge you to test the site properly before it's let loose on the web.
The site is now live, but that's not all. While the content is likely to be in your hands (through a Content Management System, for example), there are potentially two ongoing phases to consider.
The first is maintenance; keeping the 'machine' in working order and fixing any problems that arise over time. The second is development, adding new functionality and changing the look and feel of the site.
Here's a list of all the main phases for a biggish web project:
- Initial proposal
- Initial planning
- Project specification, wireframes
- Detailed planning
- Usability testing 1 - proof of concept
- Visual design
- Site templates
- Usability testing 2 - proof of design
- Site build
- Functional testing
- Well earned break!
Of course, not every website requires all of these phases; some are optional, and can be included or excluded as budget allows. And it's certainly true that not all web teams follow these procedures, but those that do will be more likely to get your concept to completion with fewer hiccups along the way.