Web Development Project Process Workflow

I've always found having a process in place for any type of project to be beneficial, and a number of different business systems have been developed over the years to guide people in project execution. In another life I spent some time in quality control at a development company, during which I studied Six Sigma and the great management philosopher, W. Edwards Deming, among other things. One of the ideas at the core of quality control systems like those is the need to document the steps required to complete a project and to use that documentation as a sort of living instruction manual that evolves as new things are learned and different, perhaps more effective, ways of doing things are discovered. This is one of the first steps in working to improve the quality of any product or service, and it's something I've been doing for a while now in a number of different areas of my business.

That said, here's a little peek at the system I've developed for web development projects. For our clients reading this, I hope this provides some insight into how we tackle projects like yours so you know what to expect during the process. For anyone else, I hope this helps in developing your own documentation if and when you find you need it.

The Project Life Cycle

The web development process is broken down into a number of separate stages; a series of stages makes up one phase of my 4-phase Web Development Process.

Phase 1 – The Introduction Phase

Introduction / First Contact

This is where the client and I speak for the first time, learn a bit about each other and this is my opportunity to get a quick overview of what the client wants. A lot of times we just send emails back and forth and sometimes we speak over the phone. Pretty simple.

Needs Assessment

During this stage it's my job to really wrap my head around just what it is the client wants and how I can deliver it. I'll also consider the client's budget and make a decision as to what my recommendations are moving forward. Once I feel confident that this is a project I want to be a part of, I'll usually send the client sort of a pre-quote questionnaire. The questionnaire is fairly detailied, but I've learned through experience that every single question in the thing must be answered before work begins on the project. Even though the client and I haven't formally agreed to work together yet at this point, that questionnaire helps the client flush out all the details of the project, which will be vital no matter who they decide to work with.

By the end of this stage, the client and I have decided to work together on this project and any necessary paperwork (contracts, formal proposals, etc) is taken care of.

The end of this stage also represents the end of Phase 1, which I generally think of as the Introduction Phase.

Phase 2 – The Conceptual Phase

This is when the actual work begins.

Pages & Purpose

At this point the client and I both have a thorough understanding of the purpose, or goal, of this particular project. If we need to refine that any further we do so here.

Additionally, we make a decision on exactly what pages will make up this project. We'll define the general purpose and a quick, one-line explanation of the content of those pages. We'll also begin to formulate a mental map of how the pages will interact with each other in the final product.

Sketches & Wireframes

It's amazing what a few quick sketches on a sheet of paper can do for your understanding of the structure of the site. The level of detailed required really depends on the project scope, but I like to do basic sketches even on the simplest of projects as it helps to ensure we don't miss any little details or potential hurdles down the road.

The term wireframes may not be totally clear to everyone…wireframes are nothing more than a rough outline of the sections of the site. Since I don't have any of my own in front of me at the moment, I quickly grabbed a few samples from the web. The first – from Greg Froh – is pretty typical…many are even just sketched on paper. The second – from T. Scott Stromberg – is an example of a sketched wireframe with quite a bit of detail…something useful on more complex sites.

Milestone 1 – Wireframe Approval

This is where the client reviews and approves the wireframes and sketches we've created. If there are any changes to be made we'll make them before moving on to the next stage. Once the client approves the wireframes, we've reached our first project milestone.

So up to now, we've hashed out the purpose of the site and most of how we'll accomplish that purpose in sort of an outline form represented by the completed questionnaire, wireframes, and any other sketches we've created. Most importantly, however, this whole time our minds have been wrapping ever more tightly around the overall picture of how this thing is going to come together, and we're ready to fill in some of the details. Those details come in the form of the Project Specification – also known as a Design Document.

Project Specification / Design Document

The project specification is a thorough explanation of how the site functions. There are a number of different standards and methods of tackling this kind of thing, but I've developed my own method that works very well for all but the most complicated projects.

There are really two major portions of the project specification, the User Interface portion, and the Design Document portion.

The first is the User Interface portion, which describes, in detail, how the user will interact with the web site. For instance, how page navigation works, explanation of what the user sees when searching the site…it's basically a detailed explanation of everything a visitor can do on the site.

The second portion of the specification is what's commonly referred to as the design document, which, according to Wikipedia,

"is a written outline of the development of a course or a description of a software product that a software designer writes in order to give a software development team an overall guidance of the architecture of the software project."

In layman's terms, the design document guides the programmers in their code-writing.

The important part of this document for the client is the User Interface portion.

Milestone 2 – Project Specification Approval

So that project specification we just created…it's time for the client to approve it, the user-interface portion at least. The design document portion is all but useless to the client most of the time and I generally don't even send it along.

It's important to note that on very simple projects, all of the previous stages combined may only take a few hours, plus approval time. On any project, however, by this point, both the client and myself have a thorough understanding of how the site will function and where various page elements will appear. Now it's time to get a more detailed visual.

Graphical Mockups

These are drawn with Photoshop and, other than some small changes, represent a snapshot of what each page of the site will look like when it's complete. I generally don't create every single page that will be on the final site, instead I create one example of each of the major templates. For example, the privacy policy and the terms of use pages on most sites have pretty much the same look with different content. In that case I'd only create one mockup to represent both of those pages.

I like Photoshop for building mockups. I've tried Adobe's Fireworks, which is actually designed specifically for creating website mockups and graphics, but I really haven't found it any more useful than Photoshop, so I've stuck with that. (As a side note, I haven't tried Fireworks CS4 yet, so maybe I'll give that a trial sometime soon).

Milestone 3 – Mockup Approval

Now it's time to send the mocukps to the client for approval. This is a major point for clients because up until now, they've only seen rough sketches and read details in a glorified instruction manual…now they get to see what their site's going to look like.

The client submits any change requests, changes are made, and when the mockups are finalized, it's time to convert them into web pages.

Phase 3 – The Construction Phase

Up to this point we've really just been designing our product. Now it's time for the product to come to life.

Convert Mockups to HTML

Here we basically recreate the graphical mockups in HTML form – web page form in layman's terms. There's no logic programmed at this point so any programmed functionality the final site will have doesn't exist, apart from the ability to click from page to page.

Adjust for Different Browser Types

Different browsers can render an HTML page in very different ways, so it's always necessary to test the pages in each targeted browser, and adjustments are usually necessary to ensure the pages render properly.

Build Application Logic

Once we've got the site templates laid out and looking good, the next step is to build the application logic. This could be a simple process or a really complex one…even the most basic sites usually have some sort of application logic to handle contact form submissions. Regardless of the size of the site, we've already detailed how the application will be built in the Design Document, now it's time to write the code.

Phase 4 – Testing & Launch

Almost done…we've pretty much got a functional site at this point.

Testing

Now I go through the entire site from beginning to end and test everything…this is admittedly pretty boring, especially because I retest certain sections in multiple browsers. Nonetheless, it's necessary as there are always a few little details that get overlooked in the Construction Phase that need to be tweaked here.

Milestone 4 – Client's Pre-Launch Check

Now's the client's chance to finally see a finished product. The client tests everything to make sure it's all working and rendering properly on his or her screen in preparation for the launch of the site.

Backup & Shutdown Existing Site

If the client has an existing site, I'll backup those files first. Then I take the site offline and put up a notification in it's place so that any visitors know upgrades are taking place and to check back later. This notification isn't absolutely necessary if it's a small site with little to no traffic, but without it you've got visitors landing on broken or empty pages during the upgrade and that just doesn't look professional.

Upload New Site Files

The new files are uploaded to the production server and quickly tested to ensure everything's functioning properly on this new server. You might be wondering where the site was before this…a lot of times I'll build a site on a testing server that I can give the client access to. The site will be built almost entirely on the testing server and then uploaded to the production server before launch.

Client Approval and Inspection Signoff

I've only just started requiring clients to signoff on an inspection sheet stating they've thoroughly inspected the site and everything is working. I like to get projects wrapped up at this point and having the client sign an inspection sheet ensures that they understand this is the last chance to have me fix anything. Otherwise, I sometimes won't clarify and I've had clients come back a month or two later asking how to do such and such or requesting an image change because they didn't have a chance to thoroughly go through and test everything when we wrapped up the project. Unfortunately, at that point I have to bill them, so this step helps prevent any misunderstandings in that arena.

Conclusion

There are some miscellaneous cleanup tasks I work on at this point, like signing over copyrights, burning project files to disc and mailing to client, and any internal business tasks I need to wrap up, but other than that, the project's complete, the client's thrilled (hopefully 😉 ), and it's time to do it all over again.

‍