Web ReDesign: Workflow that Works

Web ReDesign: Workflow that Works

by Kelly Goto, Emily Cotler
     
 

View All Available Formats & Editions

Methodologies to plan, budget, organize, and manage web design and redesign projects from start to finish.

  • Gets at the business approach to Web design!
  • Intuitive organization will make it easy for readers to find the material they need.
  • Written with the designer in mind.
Most companies redesign and re-launch their Web sites every 6 to 12

See more details below

Overview

Methodologies to plan, budget, organize, and manage web design and redesign projects from start to finish.

  • Gets at the business approach to Web design!
  • Intuitive organization will make it easy for readers to find the material they need.
  • Written with the designer in mind.
Most companies redesign and re-launch their Web sites every 6 to 12 months. The business of Website design, therefore, is one of constant change and change management. Web (Re)Design provides a framework from which to tackle the all-important planning, budgeting, organization, and management of a project from conceptualization to launch. And then the maintenance and change-management issues that inevitably follow. The book follows a road tested experiential methodology to expose the critical steps to planning, budgeting, organizing, and managing a Web design or redesign project from conceptualization through launch. The authors use a sound pedagogical style that is appealing; easy to access; and full of forms, checklists, and worksheets to assist readers in working through their own projects. The page design will allow for easy browsing of material.

Read More

Editorial Reviews

In a guide not intended as a technical manual, two Web design experts explain their five phase core process for successful Web site re-launching: defining the process, developing site structure, visual design and testing, production and QA, and launch and beyond. Enhanced by case studies, features by other contributors, foreword by a magazine editor, and color graphics. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Product Details

ISBN-13:
9780735710627
Publisher:
Pearson Education
Publication date:
01/28/2002
Series:
Voices That Matter Series
Pages:
253
Product dimensions:
7.98(w) x 10.14(h) x 0.59(d)

Read an Excerpt

Phase 4: Production and QA

Production's goals are simple: No misinterpretation of user capabilities or project goals; create a website that looks and works the same for every user. No duplication of effort; code each HTML page only once.

With the legwork and planning of the site essentially completed, now is the time to create, implement, and integrate. Phase 4 is where the actual building happens. You have defined and structured the project and have developed a look and feel � here is where you put together all the pieces you have designed, planned, and gathered. If this were pie baking instead of web design, consider your fruit sliced, your ingredients measured, your oven preheated, and your crust shaped. After one more check of your recipe, you are ready to bake.

This phase is divided into three sections � Prepping, Building, and Testing � a production workflow aimed at keeping the project's HTML construction on track. Whether your budget is upwards of $100,000 or under $10,000, the steps delineated here work for all web projects � redesigns and initial designs alike. Either way, your goal is simple. No duplication of efforts. Code each HTML page only once.

Assessing Project Status

Before production actually starts, take a moment to review the project's status. Did the scope increase? Is the project on budget? Has the all-important con-tent arrived? And is your team ready for the pro-duction task ahead?

Right here at the beginning of the production phase we must address an important fact: The web is driven by HTML. We assume that you or someone on your team has an understanding of the HTML process, either through pure hand-coding using BBEdit or Allaire's Homesite or the like, or by using a WYSIWYG editor such as Adobe GoLive, Macromedia Dreamweaver, or Microsoft FrontPage. Here's the burning question: What is the level of that understanding?

Reassess your HTML production team's capabilities now that you know the true extent of the design and technical requirements, and if you are not qualified to make the assessment, find someone who is. Coordinating web production takes both ability and experience. Depending on your team's level of expertise, you will need to determine the true level of complexity that the site production can handle. For example, if you are creating a 20- to 40-page brochure site with light JavaScript, you can probably get away with using a WYSIWYG editor. If the site is more complex � intricate tables and/or frames usage, additional scripting and/or DHTML implementation � you will need to have the knowledge to troubleshoot problems along the way, which usually means utilizing people with a fluid understanding of HTML. This tends to call for people who can code pages by hand or who at least can read and understand the code well enough to tweak HTML and troubleshoot during the production process.

And before any coding truly begins, a final just-before- production-starts review of audience needs (browsers, screen size, connection speed), technology (plug-ins, scripting, backend needs), and redesign goals (download size, user experience goals) can only help. You will have to address complex questions about servers, directory structure, and the HTML production specifics that may have been left until this phase. The Client Spec Sheet will help.

Your goal? No misinterpretation of user capabilities or project goals. No backtracking. Code each HTML page only once.

Establishing Guidelines

Establishing clear guidelines for HTML production during the initiation of a web redesign project helps to answer questions and avoid costly backtracking. The Client Spec Sheet sets parameters for audience capabilities and technical standards for the site. This is a worksheet. It is long and detailed and technical. The client may simply say, �I don't know. You're the expert; you tell me.� Some discussion is likely necessary. For instance, the project manager or lead production designer might have to explain what effect choosing to support 3.x browsers might have on being able to support certain functionality, or what effect selecting Flash might have on wanting to support dial-up modem connections, and so on.

The Client Spec Sheet is available for download from www.web-redesign.com. Due to its length, we could not show it in its entirety in this book, so we show only the first two parts: Target Specifications, and Functionality and Features (see worksheet on next page). All told, it is five parts long, as follows:

Part 1: Target Specifications
Part 2: Functionality and Features
Part 3: Design and Layout
Part 4: File Structure and Directory Preferences
Part 5: Server and Hosting Information

As tedious as filling out this worksheet may be, the information needs to be addressed and answered before any HTML production can begin, and that includes conferring with the visual designers at the onset of Phase 3: Visual Design and Testing. Encourage client feedback within a short timeframe. This information should be back to the team and analyzed before the visual designers start developing concepts and definitely before the production designers start building the Protosite.

The team's lead HTML production designer should be the team contact; the project manager may or may not be as technically savvy. Have the client � or the client's key tech lead � answer all questions as thoroughly as possible, adding additional comments as necessary. Encourage the client to write �N/A� next to nonrelevant items and to identify areas in which advice, suggestions, or clarification is needed. Filling it out should be taken seriously; the results from this analyzed worksheet serve as a set-in-stone guide for production.

The worksheet on the following pages will help you articulate and identify the technical parameters of your site redesign, including specific questions regarding target audience connectivity capabilities, browser versions, functionality, and actual file structure. When you are finished, please return all compiled information back to the project manager on the web development team.

Scope Expectations Meet Scope Reality

An estimate of 100 hours can easily turn into 300 hours if the complexity of the site has been underestimated. In Phase 1: Defining the Project, you estimated the project's budget based on the pro-jected scope. Did you plan on 50 pages and now there are 120, or are you still on target? Assess. Has your scope grown, either through Scope Creep or as a result of client-requested changes and/or additions? If so, you will need to either increase the budget or downsize the allocation of hours� or take a loss. Regardless, if you haven't yet addressed potential budget changes with your client, do it now � before you start coding. And make sure you have included resources for QA along with the time necessary for fixes...

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >