• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL



The workflow of a project is exactly that: a planned flow for the work involved.

We did not suddenly think, “Web redesign, now there's a topic for a book.” The concepts behind this book have evolved over many years. They were a direct result of the process methodology that was born out of Kelly's appearances at the Thunder Lizard conferences (www.thunderlizard.com) beginning as far back as 1997. Kelly was then, and continues to be, on the Thunder Lizard roster at several conferences each year, where she lectures extensively on the topic of web design workflow in its many stages.

As the market shifted from reengineering to redesigning, it became apparent that points specifically directed at redesigning websites needed to be addressed. And with every successive conference came The Question: “When are you going to write a book?” Kelly's PDF documents that accompany her lectures have always been widely and freely distributed, but clearly it wasn't enough, and by 1999 The Question was ever present. Then The Idea was born: Web ReDesign. But then The Idea sat. It was too big for one person.

The Kelly-and-Emily team came together over bagels and coffee. Emily, having attended one of Kelly's Thunder Lizard workflow sessions, interviewed her for an article for Publish Magazine, an industry periodical for which she had been writing for years. When Kelly read Emily's article, she realized that here was the co-conspirator who could help turn The Idea into The Book.

This book — a true collaborative endeavor — puts the topics of web management and workflow, information design, and usability all together under the umbrella of the timely topic of redesign. A guide for web development methodology, with heavy emphasis on the additional and specialized needs of redesign projects, this book is a roadmap that shows you how to proceed with minimal guesswork and budget-draining fuss.

Our focus is workflow; our process — we call it the “Core Process” — is workflow that works. It is based on our experience and expertise, and it has been tested and used in the real world, on real projects, and has been shared, modified, updated, streamlined, and simplified into what you see here today. This book provides a complete, top-down view of a web redesign plan, presented in an accessible, usable format. This is about process; there is very little preaching here.

We do not put this methodology forth as something set in stone. You are not a dummy (and this is not a dummy book); you'll know when to follow and when to modify.

A Tool Kit in a Book

We've included tools in this book — tools you can use today, as in right now, as in on your current project. We offer checklists, surveys, worksheets, and forms to help you keep your project on track from initial planning through launch and beyond. Many of these tools are downloadable from this book's accompanying website (www.web-redesign.com). These tools, like the Core Process itself, have been tested, used, and refined. Plus, we have added new and updated ones for the second edition. We received a lot of feedback on the tools after the first edition was published, and we hope that this interaction will continue.

How This Book Is Organized

The best way to use this book would be to read it from beginning to end before starting your next project. But who has the time?

With that in mind, this book is organized to be picked up and restarted and put down and skimmed over and browsed through and read in detail. We've included lots of tips and pulled additional pertinent information into sidebars. We've repeated ourselves in places. We do this because we know you are probably reading in spurts and not necessarily in a linear fashion. We don't want you to miss out on anything.

The Core Process comprises five phases, presented in Chapters 3 through 7. In addition, we supplement the Core Process with a selection of expanded steps (in Chapters 8 through 10) that, depending on your time, budget, and needs, will help further round out your redesign process.

Most readers will probably want to use this book by familiarizing themselves with the overview (Chapter 2), reading the chapters, and reviewing the tools available. Then, while actually running your project, use the overview for reference and the chapters for detail. And, of course, utilize the many tools we provide during the course of your own production, including the checklists at the end of each chapter, to help keep you on track.

Who Is This Book For?

This book is designed to streamline the process for everybody involved, not just the project manager and key decision-makers. Our goal is to put everybody — client and team alike — in the same frame of reference and have them all use the same terminology and understand the steps necessary for any web project. When we say any project, we really mean any — redesign or initial design, $10,000 budget or $500,000 budget. Truly, even if your project is under or over this range, the Core Process will still be helpful.

When we say “core,” we mean exactly that: the basic and necessary functioning parts. We like to think of “core” as a tool kit that you wouldn't venture into a project without. No matter the type of site being redesigned or the scope of the project itself, the Core Process remains essentially the same, with variation dependent upon circumstances and expertise. Approaching any project in an organized and comprehensive manner will save time, budget, and headaches along the way.

Who Are You?

Whether you are a designer, an in-house webmaster, or a company owner trying to move your web presence to the next level, this book is for you. If you have ever felt frustrated because a web project was run inefficiently (“My client delivered site content five weeks late, yet the site launch date remained immovable”), this book is for you. If you are embarking on your first web project (from “This is the opportunity I have been waiting for” to “What am I going to do?”), whether taking over your company's website or being asked to build a department to do so, this book is for you.

This book is for every person — designer and nondesigner — who has ever lived through a workflow nightmare and wants to avoid it in the future. (“We went straight to visual design, figuring we could deal with navigation and content at that stage. The result? Total disorganization and much backtracking.”) From the seasoned pro to the newbie, this book will help. If you already have significant experience, you will probably find yourself customizing the Core Process to fit your existing processes. If you are a newbie, this is the place to start — the whole process is right here.


This book also works for straightforward website development in addition to redesign. The techniques and tools modify easily and provide a solid workflow for either. If you're designing a site for the first time, simply ignore the redesign parts and focus on the Core Process.

What Kind of Company Are You?

Are you a small to midsize web development firm or a huge company with an existing intranet department? Perhaps you are a small corporation with a web department in-house or a midsize company with an outside design firm contracted. Maybe you are a sprawling university system in which every department is using a different branding…

The Core Process outlined in this book applies to all of the above and then some. It truly is a one-process-fits-all workflow.

Who Is the Client?

For the purposes of this book, “the client” is a somewhat schizophrenic, catch-all term. The client is one entity to the design house and a different entity — but not-so-entirely different — to the internal department.

If you are a design firm or web development company, the client is external — the company that contracted you. This is pretty straightforward client management.

For those of you in in-house departments, the client is internal — specifically, the person (or group) who is responsible for the content, the concept, and perhaps most importantly, granting approval. This is not necessarily the head of the internal web department; it might be a group including someone in marketing, someone in product development, a couple of VPs, and perhaps the CEO. Less straight forward client management.

Throughout this book, we frequently reference “the client.” Wherever we do so, we mean either the external or internal client — whomever is in the position to give project, budget, and design approvals. Even if you are your own client, know and accept that whether excellent to work with or patience trying, the client always requires managing. There are spots in this book where we specifically reference a situation for an in-house team with an internal client, or for a web development/design firm with an outside, contracted client. Only you can know how to interpret “the client” as it relates to you.

Levels of Formality

The management of internal projects — specifically the presentation of deliverables — tends to be less formal than when a firm contracts an outside client. This informality has its pros and cons, though none so pronounced as in the cycles of approval of deliverables. PRO: It's often as easy as walking down the hall to get sign-off, plus the level of formal presentation can be greatly diminished. CON: There is a great propensity for items to slip through the cracks in internal setups. When you don't have to formally invoice a client, the tendency to be lax on administrative details becomes more prevalent.

What This Book Is Not

No book can be everything to everybody. We focus on workflow and, at that, on a Core Process. With the goal of creating a basic (albeit comprehensive) book, we necessarily had to make the conscious decision to omit several facets of web development that were not strictly project management and workflow oriented.

This Book Is Not a Technical Manual

This book is not a step-by-step workflow for backend implementation. If your site requires a backend database, e-commerce capability, dynamic content, and so on, you need an additional, parallel plan. The workflow for the redesign is this Core Process, this book. But backend development needs its own, totally separate workflow, a whole book unto itself. However, while we don't outline the backend workflow in detail, we do indicate points in the Core Process where the front-end and backend workflows meet, where the project managers for the two processes must confer. For more on this and additional processes for working with complex functionality, please refer to Chapter 9, new to this second edition.

To this end, this expanded second edition provides not only an overview of the technical considerations that need to be clear and understood so that you can evaluate the project's scope, but also a step-by-step model to help manage a project that has both a front-end and a backend. This book provides you with surveys, suggestions, and tips, all geared toward helping you identify your overall technical needs. Our goal is to help you determine what these needs are and how realistic they might be so that you can budget and plan for them.

We can tell you for certain — and we repeat it in several places because it is so very, very important — that whatever your technical requirements, whether significant backend or not, you will want to talk with your technical team — HTML production and engineering alike — throughout the project. And yes, that means from the get-go, all the way through the lifecycle of the redesign project.

Know Your Ends

Sites are developed in layers. All sites have a design/presentation layer — essentially everything the site user actually sees. This is the graphic user interface (GUI). Some sites have an application layer, where much of the functionality that the user interacts with resides (for example, for registration, login, shopping cart transactions, personalization, etc.). The design/presentation layer and the application layer form the front-end of web development, as we know it, on the web today.

The application layer, being in the middle of the front-end and backend, sometimes crosses over between simple scripting (e.g., JavaScript, DHTML, CGI) and complex programming (for example, for shopping carts or secure transaction integration). It is the conduit and link between the front-end and backend of web development.

For sites with complex content-retrieval systems, database architecture, and massive engineering needs, a separate workflow is in order. This is the “backend” of web development.

For the purposes of this book, however, “front-end” is the design/presentation layer only. “Backend” refers to everything behind the front-end, application layer included. Please note: Not all sites have or need backend development, but 100 percent of websites have a front-end.

We have no explanation as to why front-end is hyphenated and backend is not.

This Book Is Not a How-To Design Manual

We address the workflow of a redesign project, not the specifics of design itself. We go into a cursory overview step by step of how the creative track is managed. For design graphics, we recommend Lynda Weinman's Designing Web Graphics.4 (New Riders, 2002). For site design and production, try Jeffrey Veen's The Art & Science of Web Design (New Riders, 2001); Jeffrey Zeldman's two books, Designing with Web Standards (New Riders, 2003) and Taking Your Talent to the Web (New Riders, 2001); or David Siegel's industry classic (still a great resource after all these years) Creating Killer Web Sites (Hayden Books, 1997). For more recommendations and links, consult www.web-redesign.com.

This Book Is Not a How-To Manual for Usability Testing

Again, this book is about workflow. Usability testing is definitely something we talk about — frequently. We believe very, very strongly in its value. We go into detail on the subject in Chapter 8, but primarily from a project management and workflow approach. For an immediately accessible (and entertaining) handbook on usability, we recommend Steve Krug's Don't Make Me Think (New Riders, 2000). For an in-depth background and philosophical approach, we suggest Jakob Neilson's Designing Web Usability (New Riders, 1999). Both these books remain on target despite being several years old. For actual how-to, try Jeffrey Rubin's timeless Handbook of Usability Testing (John Wiley & Sons, 1994). For more recommendations and links, consult www.web-redesign.com.


Unlike a companion CD, a website is a resource that can be updated, accessed, and actually used. The idea of creating a companion book site is not new. This one, however, comes with downloadable tools, references, and resource links. Throughout this book, we identify tools as being “downloadable from www.web-redesign.com.” We are inviting you to take these tools and use them. Please be aware that our publisher gets cranky if the copyright is removed, so credit to the book is appreciated.

The website is not a replacement for the book. Even calling the website a supplement is a stretch. It is a resource. In addition to providing all the tools featured in the book, www.web-redesign.com will include links to related sources, updated information about us (where we are and what we are doing), and of course, a section that deals with errata and the publishing time lag.

We welcome feedback and look forward to hearing from you.

Kelly Goto (kelly@gotomedia.com)
Emily Cotler (emily@waxcreative.com)
Autumn 2004

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint