Paperback

Item is available through our marketplace sellers.

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.

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)

Related Subjects

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...