The Discovery of the Grayscreen Prototyping Process

As the owner of a web development company, I've experienced many project horror stories. In the midst of some of these projects, I was tempted to give up. Many times I was at the end of my rope with a project. Nevertheless, I maintained the business philosophy that when we encountered problems, I would not look to the client to fix them with more money, but I would go back to the drawing board and look at our process to see where we could have done a better job in communicating (this philosophy was instilled in me through a wonderful book called Selling the Invisible by Harry Beckwith). We tried many approaches and saw some marginal improvements, but there always seemed to be a threshold of control that we could not reach, making projects tend toward negative experiences rather than positive ones. Fortunately, our clients have usually ended up happy, but only because we absorbed the costs of problems. I looked at this cost as the price of an education in how to communicate effectively about web development. It wasn't until the summer of 2000 that we finally hit on something that worked, and worked well with just about every client.

We stumbled upon grayscreen prototyping.


Web development is fraught with complications because it is the synthesis of three major disciplines: design, technology, and marketing. Because of this, web development projects will often include managers from each of these disciplines. Communication between individuals from these disciplines is often difficult because they each speak their own language. Effective communication must occur for them to work together to create a well designed site.


In our various attempts to find ways to communicate with all of the parties involved in a development project, I researched and explored many methodologies. Having a background in the advertising world, and because web development includes design and marketing, our original process was very similar to approaches used in advertising firms. Web development also shares some commonality with the publishing industry, so we explored some publishing processes as well. Web development also involves software development, introducing processes very different from those in advertising and publishing. Being new to the world of software development methodologies, I had to learn what was out there.

I became familiar with the waterfall model and the spiral method, and tried to integrate pieces of them into our process. One of the key components of any software development model is the documentation of requirements and "use cases."� These documents become the technical specifications or "blueprints" that rule and guide a project.


As with software development, web development required clear documentation. I looked at many examples of technical specifications in order to learn how to write them for our projects. I was boggled by the language and terminology of these specifications. I realized that such a document would not be much use to our clients. I knew that we couldn't write website specifications like other technical specifications, because our clients weren't technically trained.

This was true even when I was working for technical clients. This was because technical clients would give non-technical marketing and sales people the primary responsibility for establishing website goals and working through the development process. Their technical knowledge was not deep enough to understand all of the technical issues involved in a project. For the people without technical backgrounds, a written technical specification makes their eyes glaze over. If technical specifications were going to be helpful I had to find a way to translate them so that the non-technical could understand them.


A website is software. It is written in code, and runs on a computer. The more dynamic a site (database driven) and the more functionality it has, the wider the divide between a clients' knowledge and the product they are buying. Not many of the clients I've worked with have had experience purchasing and developing custom software. This creates a real barrier to smooth project management. Even if a developer takes the time to plan and document the specifications for a project, the client is often unable to understand what the technical specification is saying. The end result is miscommunication, missed expectations, project creep, blown budgets, and missed launch dates.


Recognizing the need for documentation written in a non-technical way, I began producing what were referred to as "information architectures" (sometimes called wire frames). These were documents that showed generic page layouts and reflected the overall structure, content and functionality of a site. Each document page would detail the content of one website page. They were visually generic, but would clearly detail the site's navigation, categories, tools, content and features. I would represent almost every site page in this manner. On each page I wrote a description of its features. These information architectures were lengthy and took a tremendous amount of time to produce and review with the client. They helped, but we constantly found that when we were well into the design and development phase of a given project, we would still find that our clients had many unmet expectations. They had not understood (or had forgotten) what we had documented. I was stuck. I began to think that there was just no way to communicate this stuff clearly enough to avoid these problems.

Then an idea occurred to me...


There is an inherent limitation when trying to communicate a nonlinear, hypertext object (a website), in a linear, non-hypertext way (paper). My idea was to try and recreate the exact same information we put into our information architectures, but create it as a functional HTML model. Would this small change alter the way a client reviews a website plan? Would it make a difference? It did, in more ways than I could have imagined.

I discovered that viewing a website specification as a working HTML prototype was by far the best way to understand how the site was intended to function. This is not surprising since the web itself represents a true paradigm shift in how we relate to information. The web, unlike all other forms of communication, is non-linear. Other means of communication (books, magazines, television, etc.) are linear. Hypertext is completely non-linear. It allows for the pages in a website to be viewed in any order. A visitor might start from a sub page, perhaps following a link or a search engine query. Even when the home page is their starting point, a visitor may take one of many possible paths through a site. The structural differences between linear and non-linear information (to say nothing of the technical issues involved) can cause significant problems in communicating about the structure of a website.

Creating HTML prototypes allowed us to communicate about a project using hypertext, a medium consistent with the final product. While it was close to impossible to describe the functions of a website on paper, actually clicking through a site model communicates very well. By building a simple HTML prototype of the site prior to the design and programming phases, we were able to create a technical specification and translate it into something everyone could understand. This prototype could then be used to educate and communicate with the client about the many detailed and complex issues of web development in a way that is clear and understandable.


Our first prototype was a desperate attempt to document our projects more effectively. We had already been writing information architectures in order to provide our clients with site details. Using an HTML model of the site instead of a printed document was simply an effort to more effectively communicate the details of a site.

As we started to use this HTML prototyping method, we discovered that it was doing so much more than documenting. It was enhancing our ability to communicate with our clients. When they had questions about how something was supposed to work we reviewed the prototype and discussed the issue in its context. It was during these interactions around the prototype that we began to realize that our clients were able to give me much more detailed feedback about how they wanted a site to work. If they had an expectation about how a particular feature would function, it would generally be discovered at this early stage. We could then deal with the expectation appropriately. If there were technical limitations or cost issues discovered, we could work them out and provide viable alternatives before they became crises and before they had already been developed differently.

We found that building a comprehensive, simple HTML model of the site helped to solve many of my problems. The prototype also performed the function of a technical specification (we began to add programmer notes to the pages) that accurately described the structure, content, and features of our sites.

Because we translated the specification into a familiar HTML model, it was something our clients could grasp. Additionally, clients spent more time looking at prototypes. They considered them more carefully than paper documents, because they understood what they were looking at. We were able to get the kind of detailed feedback that we used to get only after a site was almost complete. This solved many of the problems that stemmed from our clients' expectations. By using the prototype to define and specify sites, we were able to communicate and educate our clients in an effective proactive manner. This improved the overall flow of information, which resulted in positive relational dynamics with our clients.

With all of the gains we experienced through grayscreen prototyping, we were able to effectively and consistently overcome the barriers that are so common to the web development process.