As far as possible, we try to use a standard process for our web projects. Although it can seem like overkill for smaller projects, one thing I've discovered is that when it comes to building web sites for large organizations, there really are no shortcuts.
If you cut corners, it will always come back to bite you in the end, whether it is in the form of last minute design or content changes or a site that just doesn't meet users' needs.
We use this to develop our project plan and we present it to customers to explain all the steps needed to develop their site and help them understand why the timeline is what it is (i.e. why it's so long).
Our workflow goes through seven stages:
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'.
This is where the project is defined. The key tool for doing this is the creative brief (learn more about how to write a 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.
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.
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.
Design begins with the development of the site's information architecture and the testing of it using lo-fi prototypes which I usually mock-up in PowerPoint.
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'.
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.
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.
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.
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).
Kelly Goto's Web ReDesign 2.0: Workflow that Works takes you through the process of developing or redesigning a web site by following a series of clearly laid out steps organized into five stages.
This is a practical, great looking book that that contains lots of examples and guides to make the development process as straight forward as possible.
It's well worth a read for anyone serious about improving their web development methodology.
Posted on: February 20, 2006 | 5 Comments