Introduction

As the owner of a web development company since 1995, I've experienced the thrills and terrors of riding the web development roller coaster. I began this ride when my then employer Bruce Leonard (then president of Leonard/Monahan Advertising) asked me to incorporate web design into the agency's capabilities. Most of what I know about computers I learned from reading books. So I went to Barnes and Noble and bought my first book on HTML: Laura Lemay's Learn HTML 1.0 in 7 days. Soon I was building web pages with SimpleText and viewing them in Mosaic. I was hooked. I created my first website for Etonic Athletic, my second for Polaroid, both while working as a freelancer for Leonard/Monahan. I was able to parlay these jobs into many others and soon I had started my own web development company, Newfangled Web Factory. Because of my background in advertising, many of our projects came to us through advertising agencies and design firms. The first few years were fast paced and difficult. Our web projects were fraught with miscommunication, exaggerated expectations, and negative relational dynamics. Early on I assumed that this was simply a consequence of working with a new technology. Later I discovered that the problems ran much deeper than that.

Up until the middle of 2000, Newfangled's development process was much like that of every other web development company. The process started with the "planning/strategy phase," followed by "design," then "programming/testing," and finally "launch/maintenance." Like most web developers, we thought our process was carefully thought out and logical. However, while the process seemed to make sense, it didn't work. No matter how hard we planned, our projects would slowly degrade and unravel. The downward path of our projects was not due to lack of effort. At one point we were creating generic screen illustrations prior to development that showed how all the proposed content, features, and functionality of a site would fit together. These documents were usually 20-40 pages long even for relatively simple sites. They took a long time to write and even more time to review with clients. In fact, we were investing so much time in planning that clients often grew impatient, wanting to "see something" instead of just discussing the site and reviewing specifications. Yet we knew that if we rushed the planning stages, we would pay for it later. Unfortunately, even when we thoroughly completed the planning stages, problems would still surface, usually in the final stages of the project.

It's been said that necessity is the mother of invention. Well, I definitely needed to do something. It was around this time that I did some analysis of my business and discovered that we regularly invested two to three times the hours budgeted on almost every project. There was no way we could double or triple our budgets (especially since we were in the middle of the dot com crash). I had to figure out a way to effectively communicate about the subtle details of a website before we got into the time intensive design and programming phases.

This book is about a wonderful discovery that transformed our web development process and saved my company. This discovery allowed us to clearly communicate the subtleties of a website to non-technical clients. Our clients "got it" and were able to confidently move through the entire development process. As a result of this simple discovery, many of the advertising agencies and design firms that we work with have become much more comfortable, confident, and profitable in offering web development services to their clients.


This book is for anyone who has been, or will be, involved in developing a website. There are many parties involved in the development of a site, some are technical, some creative, some strategic, and some managerial. I am primarily writing for those poor souls (often Marketing Directors) who are tasked with the responsibility of leading a team in getting a website built or redesigned. They will benefit from this discovery because it gives them a means of understanding the subtleties of hypertext, and the technical complexities of the web. Their projects will be greatly improved through identifying and overcoming the common barriers to communicating about the web.

I am also writing for both account executives and creative directors who often get stuck in "no win" situations as they try to meet their clients' needs for web development. These communication professionals are often caught between the exaggerated expectations of their clients and insensitive web development partners who don't grasp the complex relational dynamics and corporate politics that can govern a decision making process. Trying to mitigate these two diverse perspectives can be extremely frustrating for them. In fact, it can be so frustrating that many agencies and design firms have given up on the web entirely. The approach we put forth in this book places a high value on communicating technical complexities to a non-technical audience. Understandable technical communication is the key to resolving these frustrations.

Usually, our clients come to appreciate our process after we have proven its effectiveness. By contrast, our agency partners recognize its value simply through an explanation of how it works. I think this is because of two traits common to most agencies and design firms. First, they value effective communication, and second, they have become extremely frustrated with not being able to communicate effectively about their web projects. They quickly grasp the value of our process when they understand how it facilitates effective communication.

Finally, and to a lesser degree, I am writing for other developers. The benefits of this process should be obvious to them since, like us, they contend with the barriers of communicating web development every day. We have deliberately described our process in ways that can be adopted by any developer, using generic web development tools. The core idea behind the process is technology agnostic.

The main subject of this book addresses how to communicate technical issues non-technically (for the benefit of clients who don't have technical backgrounds). Because this is our aim, the technical developer may find the lack of precise technical language disconcerting. However, this is necessary and deliberate. I would appeal to the technically literate developer to consider how important it is to be able to translate technical issues into non-technical language, especially when it comes to the web. Websites, after all, are custom software applications that are purchased by people who have never bought custom software, making them completely unfamiliar with the language of this endeavor.


The primary subject of this book is communicating the web development process. I start by using a fictional story (based, sadly, in reality) that describes the common frustrating experiences many have endured when designing and building websites. The story provides a backdrop for analyzing issues of miscommunication, which is the root problem that causes web projects to break down. I then examine how exaggerated expectations and poor relational dynamics, stemming from miscommunication, complicate and compound the breakdown. Finally I describe the breakthrough discovery of a simple method of communication that addresses the root problem and transforms the web development experience.

I discuss the principles behind this new communication process, highlighting its many benefits. I also offer some specific help and ideas about implementing the process.

The book then transitions to the subject of information design. I have debated whether this book should actually be broken up into two separate books, one on process and the other on information design. However, I believe that these two distinct subjects are so closely tied together in practice, that it is worth keeping them together in one book. Because the communication process is the primary subject, I have only provided an overview of information and limited it to the context of the web. I believe that without a solid communication process, the skill of information design will continually run aground. Yet even a proven process, without careful attention to the principles of information design, will not result in a well-designed site. Thus the second part of the book discusses information design as a corollary subject to the primary subject of communicating the web development experience. The intent is not to be an end all discussion of website information design. There are so many better books and websites on this subject. Instead we want to cover the basics, but more to give an appreciation for the importance of information design to whomever is involved in the planning stages of website development.

Again, audience has modified my approach to the secondary subject of information design. I've addressed it primarily with non-web developers in mind. Specifically, I considered the needs of designers and art directors at our partner agencies that must exercise their skills as visual designers, within the context of the web. These talented designers are often frustrated when technical and structural issues compromise their designs. Hopefully the principles provided and practical help suggested will help make their web design experience more comfortable, enjoyable, and effective.

To this end I also write a monthly newsletter about website ad internet related topics. The web changes fast and for the non internet oriented marketing firm, keeping up with the latest technologies is a daunting task. Our Web Smart newsletter provides digested information about the most relevant web issues written for the agency that's not daily in the stream of website and internet trends.


The following narrative is fictional, but just about every detail has been drawn from real life experiences. I've had the opportunity to read this narrative at a few speaking engagements. I usually get several chuckles (and even more groans) from those in the room who have been involved in web development projects. Unfortunately, these experiences, to a greater or lesser degree, are common to almost every web project. The narrative highlights problems as a means of drawing attention to the underlying factors that cause them. The remainder of the book's first half will discuss the solution.