First off, why document and follow a process? What are the benefits and pitfalls in doing so and how can we safeguard the process, from, well, the process?

The process needs to be document in order to institutionalize the way we work. Documentation also aids us in helping to educate new team members as well as to unveil the mysteries of what we do for clients and stakeholders. The benefits of following a process are that the project goals actually become tangible and manageable because we know that if we follow the process we will more than likely have a desire outcome and thereby attain the goals. In other words, we follow a process so we can hit what we are aiming at. We can’t hit what we don’t aim at and if we don’t aim to hit something we’ve failed before we’ve begun. That is if the goal is to hit something. Believe it or not I have worked with individuals in that past that cognitively acknowledge a fly by the seat of your pants methodology. These individuals believe chaos is the key to success. These same individuals usually work alone, or attempt to control the entire set of functions required of a web team.

The benefit of following the process produces clarity where chaos usually exists. It is a safeguard against people making decisions in a vacuum. When it works, its means a team has actually obtain project success without distorting the goals defined before the project begun.

Documenting and following a process is a slippery slop indeed. By defining a process and setting out to comply with the process we risk expanding phases excessively, becoming rigid about the order or duration of each phase, or even over-documenting the elements within a phase. At times the process can take on a life of its own and make demands that exceed the requirements of the situation. Bottom-line, know the pitfalls and plan accordingly. This function is usually done by the Project Manager and can make or break the success rate of any sized web team.

How does one safeguard the process? I believe this is a matter of keeping the process nimble and flexible but at the same time sticking to the framework (fundamentals) of the process. It’s a balancing act not unlike most things.

Some run scared when they are asked to follow a process, but in my experience the process in and of itself is good. What's not good is not having an individual responsible to manage the process. All too often I see people attack the process when really they should be attacking the decision to proceed on a process based discipline without a leader or solid requirements.

My intent from this point on is to explain the fundamentals of the process (basic framework). Wouldn't you rather get from concept to completion successfully? Then it’s all about the process. Remember, the process should be nimble and flexible but not expendable. In a corporate setting we live and die by the process because we don't have complete control over communication channels.

I believe a generic process that can be followed by most web teams can be broken down into 5 main phases.

phase 1: Defining The Project

phase 2: Developing Site Structure

phase 3: Visual Design & Light Technical Testing

phase 4: Building Phase

phase 5: Launching Phase.

Phase 1 of the process: Defining The Project (discovery, planning, clarification)

I shouldn't have to say what I am about to say but I am going to say it anyway's. As humans we are so engrained with actions we often forget the initial thoughts that get put into our actions. Yes, we have to think before we act. In fact it’s common practice to insult those who do not think before they act. Some dismiss the planning phase of the web development process as prohibiting them from getting to the actions. I say a desire for actions alone prohibits us from thinking, and thus from planning. That’s just stupid. So it should be no surprise that the process starts with an extended planning phase of jumping through some hoops.

1. discovery (phase 1.1)
   • gather Information
   • clarify and recognize intended users & users goals
   • analyzing the industry
   • identify site goals/business goals
2. planning (phase 1.2)
   • creating a project plan
   • setting the budget
   • creating schedules
   • assign the team and the rolls of the team members
   • planning for user testing ( internal vs external )
   • Site Specifications ( supported browsers & operating systems, domain names, hosting, client side programming languages, databases, sever-side web programming languages, as well as technologies/applications already implement that must be used or designed around )
3. clarification (phase 1.3)
   • clarify site goals to two or three objectives
   • prepare a creative brief
   • project kickoff

Phase 1 Objectives Summary - This phase ensures the stakeholders and development team are on the same page regarding measurable business goals, targeted users & user goals and project expectations. The scope of the project is defined, along with budget, timing, and deliverables. Overall goals are clarified by creating a comprehensive project plan, schedule, creative brief, user profiles & expectations and, if required, a technical specifications document as well as a technologies used document.

Deliverables - Project Goals & Expectations, Project Plan, Schedule, Creative Brief, User Profiles, Technical Specifications/Complex User Task Flows, Technologies Used or Needed ( aka. Site Specification ), Purchase Domain Names

Phase 2 of the process: Developing Site Structure (content development, site view, page view)

1. content development (phase 2.1)
   • content inventory
   • auditing existing content
   • outlining content
   • create content delivery plan
2. site view (phase 2.2)
   • site map ( detailing each page of the web site in some capacity )
   • application flow if applicable ( web applications and complex transactions )
3. page view (phase 2.3)
   • wire framing ( addressing interaction design for web applications/transactions and for web sites focusing on information architecture )
   • naming & labeling
   • defining key user tasks

Phase 2 Objectives Summary - Planning the structure of the site from a content and informational perspective is the blueprint for the project. Just as you would not start building a house without first planning the plumbing, wiring, and architecture, you would not start designing a site without taking the time to define content, site structure and site functionality. Content development and site structure (site view & page view) are developed in a parallel process at this stage.

Deliverables - Content Outline (bulleted format), Existing Content Delivered, Rough Site map, Rough Page Layout with Clear Labeling (wire frames), Content Delivery Plan

Phase 3 of the process: Visual Design & Light Technical Testing (designing, confirming, handing off)

1. designing (phase 3.1)
   • flat designs of the web site or interface based off the wire frames
   • visual design, information design, interface design ( aka. navigation design )
   • develop concepts and balancing tone, look and feel with user goals (marketing & branding)
   • designing for the user (based of the project specifications, goals, expectations)
   • presenting designs based off wire frames to stakeholders & technical team members for feedback
2. confirming (phase 3.2)
   • client-side & web programming prototyping ( in other words, what was wire frame should also be technically possible. This might involve database schematics, information flow charts, identifying the technologies and information used to accomplish what has been wi reframed. )
   • testing functionality, navigation, user interaction, and application flow based of the visual design, information design, and interface design
3. handing off (phase 3.3)
   • graphics are chosen and created (buttons, images, icons, navigation elements, stock photography, color palette, graphics)
   • visual designers hand off flat designs and graphics to client side programmers
   • a style guide is created for client side programmers and marketing stockholders
   • templates are outlined, discussed, and planned (main page templates & sub-page templates identified from design comps.)

Phase 3 Objectives Summary - Goals include balancing tone, look and feel with user goals (task-oriented), and confirming business goals/objectives match the users expectations as well as the stakeholders expectations. Company branding, logo usage, color treatment, and visual cues are combined with the information design, messaging, and visual design. At this stage the overall user experience should be complete. Any technical components are tested and verified before production starts. The visual design, information design, and interface design process is completed which includes time for revisions & approval . Content development ( started in phase 2 ) should be complete by the end of this phase. A QA Plan is created for implementation in phase 4.

Deliverables - Design Comps., Template Plan, Graphic Collateral, Stakeholders Approval, Technical Approval, Appropriate Feedback, QA Plan

Phase 4 of the process: Build Phase(Technical Prepping, production, testing)

1. technical prepping (phase 4.1)
   • assessing project status
   • establishing guidelines for development
   • setting file/directory structure
   • establishing SEO (search engine optimization) techniques.
2. production (phase 4.2)
   • slicing & optimization of graphics
   • building the html pages with SEO in mind (including css, javascript and xml)
   • populating web pages with static content for permanent usage or temporary usage in consideration of dynamic content being populated from a database.
   • building application logic (actual back-end programming) as well as database setup
   • start integrating backbend development from the web programmers with the work the client side web developers have done.
3. testing (phase 4.3)
   • prioritizing & fixing bugs
   • quality assurance plan is performed
   • conduct final checking

Phase 4 objectives summary - The built graphics from phase 3 and client-side code ( xhtml,css,javascript,xml ) is applied to the finished visual design templates to create the final client-side portion of the production phase. Quality assurance is performed according to specifications/goals and QA test plan. Site content is proofed, site is deployed to staging area for final proofing and site is launched for public testing, reviewing, and debugging.

Deliverables - Proofing and sign off, Bug-tracking, Future Feature list, File structure, Meta Content, SEO plan, Bugs fixed, Programming and Client side Coding Completed.

Phase 5 of the process: launching (Documentation, launch, maintenance, post mortem)

1. documentation (phase 5.1)
   • design/style guide completed
   • site administration guides/site documentation's concerning internal usage is completed
   • site/application training if applicable
2. launch (phase 5.2)
   • perform an announcement plan
   • register with search engines
   • Consider using Google AdSense or Overture.
3. maintenance (phase 5.3)
   • understanding internal vs external maintenance
   • confirming site security
   • developing a maintenance plan
4. post mortem (phase 5.4)
   • measuring success

Phase 5 Objectives Summary - Style guide and site documentation is completed in order to assure a successful launch and in consideration of maintenance after launch. Phase two items from the future feature list is addressed and possible phase two additions begin.