Website Development Methodology - Part 1

Why Methodology?

In my years of developing websites, I have seen many methodologies, processes, etc. In this article (and depending on interest - future articles) I’ll describe what I’ve found to work well and share some of the tools and deliverables that accompany a good web development process.

The first question is why should you have a process in the first place? The answer is to keep everyone informed of the progress of the project, what is expected, and to be able to see what’s coming next and track progress. The client (in our case an external client - at a company often an department or group of people) can gain visibility into how web sites are built - many have limited or no experience with getting to a good web site. Once the project has begun, the client should understand what is expected of them and where the points of no return are. A well articulated methodology and strong project management that ties back to that methodology are key to keeping a client up to speed. Internally, a methodology serves to ensure that the proper thinking is done up front so that time is not wasted on building the wrong things. It also ensures that the team knows what their deliverables are and where in the project they are.

Throughout this article, I will refer back to the concept of building a building.  People often come to me and say “I want a website - how much will that cost”.   That equates to “I want a building, how much will that cost”.. Obviously, there are tens of thousands of questions to answer in that analogy.  Some obvious ones:

• On what land? Do you own it or do we need to buy / lease it? — What platform? Does it exists?  Should we buy for client or host with ISP?
• What kind of buildign will it be (house/office/store/gym/community center)?  — Corporate site/Intranet/Ecommerce Site/Gaming Site/Community Site)
• How many people will it need to accomodate (a skyscraper or a garden hut)? — A small targeted community of 500 or the next Myspace
• What kind and how many of rooms will you need (bedrooms/cubicles/auditoriums)? — What kinds of functions will your site need to perform and how many functions will you have on the site
• What kind of aesthetic should the building be (spanish style/modern/craftsman)? — Web 2.0 style, sleek and corporate, fun and entertaining.
• How polished would you like the finishings to be (Home Depot special or Dornbracht?) — Do you want custom photography, AJAX interactions, and 27 rounds of creative review or are you happy with any “professional / on brand” design as long as it works functionally.
• Will you be needing to expand in the future and where (having more kids, or when you have the money, you’d love to have that back porch and pool)?  — What new information / functions / users will you want to add to the site in future releases and how should the site be built to accomodate those items.

Had enough of the silly analogies cause I can keep going.  Thought so.

Methodology Overview

Define

The first phase of a project should be oriented around understanding WHAT the project is about. What are the:

• Audience requirements
• Brand and creative requirements
• The browser & front end requirements
• The systems and integration requirements
• The technical and functional requirements
• Performance and scalability requirements

Typically, this information is found through interviews / audits of the current systems, sites, materials, brand guidelines, etc.  In the phyical world, this would be defining what type of bulding to build, approximately the number and types of room, specifying the need for phone systems, plumbing tie ins, etc.  The deliverable is the Requirements Document which contains the following items:

• Final project schedule
• High level site map (preliminary)
• Wireframes of key pages (enought to show what the core functions are)
• High level systems and hosting diagram (preliminary)
• Creative brief (including mood boards, picture studies, personas, comparison sites, etc.)
• Requirements documnet (combining all the deliverables into a cohesive document)

Design

Now that we know what we’r going to build, it’s time to design HOW the site will be built.  This is equivalent to a blueprint in building a house - exaclty how are those rooms laid out, what colors to paint, who will be the subcontractors, etc.  By the time the design phase is complete, there should be no question as to what is being build (down to the finishing details) and how it will all be put together.  The items in a typical design document are:

• Site maps and wireframes of key pages
• Visual design and style guide for key pages and all elements in site
• Systems architecture (what machines, how many, what os / web server, etc.)
• 3rd party software specifications (which applications are installed, how are they customized / integrated)
• DB Schema and explanation (full ERD with explanation of what tables and fields are used for what)
• Functional specifications (desciptions of all the funcitons on the page, coding notes, reference to DB tables and wireframes)
• Coding specifications (describing front end / back end stanadars and naming conventions, directory conventions, image naming conventions, etc.)
• Final development and deployment plans

Develop

Knowing what needs to be built and how, the development phase can begin.  During this phase, the site or applicaiton will be built out.  Like in the real world, documents are good, but daily review by the architect of the progress is crucial.  The tasks need to be executed in the right sequence with an overall vision for the end product.  During this phase, trying to always picture the end product and focussing on the key building blocks is the best policy.  This is typically done by daily scrum meetings where each of the developers has tasks reviewed.  It’s the job of the project manager and account manager to monitor progress, make adjustments, and keep the project on schedule.  Typical tasks during development include creation of:

• Detailed design for all elements on the site (Creative)
  • Header, navigation, H1 – H5 elements, form elements, treatment of images, treatment of search / results tables, step 1-x wizards, etc.
• Master HTML templates for all pages (Front End Development)
• Final HTML/CSS code for all pages on the site (Front End Development)
• Integration of HTML/CSS into back end infrastructure so the end product looks the same as the HTML templates (Front End Development)
• Final JS/Flash/AJAX for any interactivity on the site (Front End Development)
• Alpha version of all functionality using the generic HTML wire frames (Technology)
• Beta version of all functionality specified (Technology)
• Functional QA on development servers (QA)
• Working code to import / export information from the system (Technology)

Deployment

One the QA is completed on the development servers, it’s time to get the site live.  This involves not only moving the code, but wrapping up all the loose ends on a project and training the person who’s going to continue to maintain the site.  This is the time to sweep out the corners, get all the instructions together, verify all dimensions, etc.  Depending on where the site will be hosted (in house vs externally)and who will maintain it, the deployment phase is different on different projects.  Sometimes the site is simple and the environment is identical to development and this is a fast process.  Sometimes the final deployment is as difficult as the development as the environment may be very complex, tie ins to other systems need to be established, and completely new team members (from IT) need to be trained on all the componenets.  The typical deployment tasks are:

• Finalized annotated PSD files for future development (Creative)
• All source code (Front End / Technology)
• A full license for City of SF (DTIS) to use the code for business use as defined in the MSA (Technology)
• Working code on final development environment (Technology)
• Final integration testing and data import assistance (Technology / Consulting / QA)
• Final QA checklist for the site and bug tracking system (Consulting)

By following this (or another well thought out) methodology, your projects have a higher chance of succeeding and the end product will be more useful.  Try to understand why this is and explain it to all team members (on your team and in client organizations).  Each project will be different and this methodology should serve as a guide.  But don’t think that a website (or building) can be built without knowing what you’re building first, how your’re building it next, and without good supervision during the development and deployment process.

Posted by A. Kaplinsky

This entry was posted on Wednesday, February 20th, 2008 at 6:41 am and is filed under Web Development Process. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.