The Seven Phases of Web Site Developement

Our workflow goes through seven stages:

• Concept
• Discovery
• Content development
• Design
• Development
• Launch
• Post-launch

The web development workflow diagram breaks down each of these phases into high-level tasks. These tasks often involve milestones or checkpoints that need to be met or in deliverables that need to be produced - these are all identified in the diagram.

In addition, some tasks have templates that can be used and others have guidelines that can be followed. This increases the level of standardization across projects and avoids 'reinventing the wheel'.

1. Concept

This is where the project is defined. The key tool for doing this is the creative brief. It is the document we go back to if we have questions about the goals or requirements of the project, or if scope creep threatens to interfere.

Once the scope of the project is fully understood a project plan can be developed.

2. Discovery

The discovery phase begins with the kick-off meeting in which the project is officially started. This phase largely involves research - into the competitive landscape, into users' needs and goals, and so on.

Various elements of the web site outlined in the Concept phase will likely get amended based on the results of this work.

3. Content Development

Content development and #4, Design, actually tend to occur concurrently rather than sequentially. For instance, we need to have a good idea of the information architecture of the site (which is done in the design phase) before we start developing the content.

And, as the content is developed, it will typically impact the IA - adding or taking away pages or (rarely) even sections of a site.

4. Design

Design begins with the development of the site's information archictecture and the testing of it using lo-fi prototypes.

This testing phase is critical as it's very easy to make changes here that would be very time-consuming to do later on in the project.

Once we have the web site IA worked out, the actual visual design is done and approved. We try to build in sufficient time for the visual design piece to be as iterative as needed - there's nothing worse than trying to be creative when up against a really tight deadline.

It's really important to get the design approved before starting phase #5, Development. It's much easier to do rework in Photoshop than in HTML, so it really saves time to make sure that the development phase just involves building out the site and no designing 'on-the-fly'.

5. Development

This phase involves building the site template and then the pages themselves. We like to review the site template before the bulk of the pages are built out to make sure that the coding is up to scratch.

It's not uncommon that some design tweaks get made during this phase, as we're always having ideas about how the site can be improved.

However, if these ideas could cause a material slip in deadlines, they may well get pushed back to a 'phase 2' enhancement. We also like to do more usability testing on the actual site to make sure we haven't missed anything.

And, of course, the site goes through a thorough content and code QA check.

6. Launch

In theory, launch is pretty straight-forward. We never launch on a Friday (who wants to be working late into Friday night, or on a weekend?) and make sure that the appropriate IT resources are available for support.

Once we've launched the site, we'll do a complete link check and also check that any applications are working fine.

7. Post-launch

Once the site is live, we set up a maintenance plan with the client. We'll then do an internal project post-mortem among our team, and later on with the client.

It's really important to do these, so that you can learn from things that went well and things that didn't.

Exceptions to the Rule

How closely we actually follow this methodology depends a lot on the size of the project and the amount of time we have to complete it.

It's not uncommon for us to skip steps based on these factors; however, if we do so because of client constraints, we make sure they understand the potential implications - for example, cut back on research and your site may not meet users' needs; cut back on usability testing and your site will be harder for people to use).