Benefits of the Grayscreen Development Process

Having uncovered a method of effective communication with our clients, I discovered many other benefits to our new process of grayscreen prototyping.


Not only did our clients understand prototypes better than other forms of documentation, they also paid closer attention to details. The input and feedback they provided was much deeper and far more thorough having "clicked-through" a prototype. We were able to address many of the "what ifs" that inevitably come at the end of projects, before design or programming began. Often, aspects of functionality and usability do not (and cannot) occur to the client until they experience a site directly. It is impossible for a client to define every possible feature or functionality they might want at the beginning of a project. But giving them something to experience and react to will help them to understand and imagine what a site could be, at a time when changes are still painless.


Before grayscreening, our development process was slow and frustrating. Getting a site map finalized and a design approved were the first steps in the process. Once the project was in HTML phase, the production staff inevitably would think of some excellent suggestions. These suggestions would have improved a site, but if they required modifications to a site design or navigation, the ideas would rarely be incorporated into a site. Typically the budget would already have been stretched and the idea of returning to a client with changes they did not initiate was akin to masochism. So this valuable and helpful insight would be wasted.

Programmers likewise would often be brought into a project after most of the site functionality was defined. Their ideas were also often overridden by budget and schedule constraints.

The initial grayscreen prototyping process utilizes the entire development team: information designers, project managers, HTML and database programmers, and visual designers. As they review the prototype at various stages, each participant has many opportunities to provide insight and perspective, weighing in on the project before it is finalized. It allows them to ask important questions about the prototype before approval is sought. HTML and database programmers often recognize ways to simplify features. They could not provide this insight if the features were not modeled and fleshed out in a prototype.

A prototype elicits a client's insight as well. In the same way that all the different players within the developer team get to see and contribute to a prototype, a range of individuals from the client's organization get the same opportunity. The more people that review and comment on a site prototype, the more fine-tuned it will be.

Because grayscreening is a team-centered approach, each team member does a better job when it comes time for them to do their part. They are more informed about the project as a whole and they have a greater sense of ownership after having been included in the team from the beginning, and contributing to the overall process.


A prototype communicates the structure, content and functionality of a site. The functional aspects of a site are often the hardest to communicate. Miscommunication and misunderstanding of site functions can lead to the biggest problems in web development. Functional aspects of a site usually require custom programming. Custom programming is hard to explain to non-technical people and once custom programming is completed it is usually the least flexible aspect of a site to change.

Mocking up site features and using programmer notes can simulate a working site in ways that other forms of modeling (site maps, written descriptions, wire frames, drawn schematics, etc.) cannot. For example, how a site will save data to a database, search a database, or create visitor profiles, can be mapped out through a prototype. These series of screens can simulate the functionality of the final site. These screens also contain programmer notes that explain what will happen to data. They might mention if it could be stored, passed on to the next page, or added to a profile. These subtleties are often overlooked and can come back later to cause significant problems. Mock ups and programmer notes are an effective way to translate technical specifications both for programmers and clients.


A prototype allows us to rework the structure, content and functionality of a site without doing extensive, time consuming, and expensive redesign and recoding work. In many development projects it's not until a site has already been designed and programmed that a client is able to click through a site. It is only then that they notice things they wanted (or expected). To make changes at this point is not only costly, but time consuming. The end result is delayed launch dates and expanding budgets (or the developer losing money). In any case, the experience is less than satisfying for either party.

The opposite is true of prototyping. The simplicity and flexibility of a prototype allows us to go through many rounds of changes until a prototype is complete. Clients feel free to iterate and request changes to a prototype because it is so flexible, resulting in deeper specification (that the client understands) and a greater understanding of the project.


I believe strongly in the maxim "form follows function." Design should always revolve around a predefined function or purpose. Too often sites are designed prior to full project definition.

When designs are created without a final structure and function in mind, they will never be as good as they could be. When the design phase follows a fully worked out prototype, it will be more focused and specific to the defined structure, content and functionality of the prototype. Visual design that is based on clear specification will always be more appropriate and compelling than designs created prior to full project specification.

Graphic designers are trained in a visual language whose purpose is to clarify information. When most people think about design, they think about making something look good, making it aesthetically pleasing. They think about things like color, typography, layout, and images. While these are aspects of design, they are far from being the extent of the designer's work. Emil Roder wrote "To design is to plan, to order, to relate, and to control. In short, it opposes all means of disorder and accident." These words more fully describe the heart of design. Design is the opposite of disorder. It suggests intention and deliberation. Good visual designers are concerned with communication, how they can clarify a message and how they can move the eye through information in an appropriate way. Designing without specification is like laying out a brochure without knowing what it is supposed to say. When a website is fully specified prior to the design phase, the designer can do a better job of clarifying. Without specification, all that is left for a designer to do is decorate.


In the imaginary (albeit all too real) example of the woeful tale, the client was not thrilled with their layouts when they were first presented. I have found that one of the reasons clients to react negatively to a proposed layout is fear. Their fear stems from a sense that the developer has not yet fully grasped what they have in mind for their site. It is very hard for anyone to divorce their view of a layout from their actual expectations of what a site should be and do. Trying to get the "look and feel" of a layout approved, before working through the content and functionality of a site, requires the client to divorce themselves from their own expectations. It is the developer saying "trust me" before progressing far enough into the project to earn trust. This is asking too much. Any negative reaction from the client at this point only sets the stage for further mistrust and fear (a downward spiral).

Having recognized this dynamic early on in our own experience, I realized that we needed to spend more time analyzing our clients' needs and planning the overall strategy for the sites. While this was the right thing to do, it created another negative dynamic, waiting too long to "show something" to our clients. Strategy and planning can take a long time, too long for most clients to wait to "see something." This dynamic is often what drives the premature creation of "look and feel" layouts.

I had a dilemma. If we spent an adequate amount of time planning, we risked the negative effect of taking too long to show the client something. If we showed them layouts before clearly understanding the project we would usually miss the mark. It was a real catch 22.

With grayscreen prototyping, we found a way to turn these negative dynamics into positive ones. By entering into the prototyping phase right away we were able to "show them something" very quickly. Clients felt free to change and restructure a prototype. The back and forth at this stage not only facilitated a clear understanding of our clients' needs, it also built our clients' confidence that we understood what they wanted. A prototype "showed them something" while at the same time gathering information needed for design and programming. When layouts are presented after the prototyping phase is complete, the client no longer worries that the developer does not understand their needs. When they do see the visual designs, they are not encumbered by concerns about structure, content, and functionality. Instead they simply respond to the designs themselves.


Grayscreen prototyping takes problematic dynamics in web development and turns them into positive dynamics. This is also true in the area of content creation and delivery. There is a real "chicken and the egg" dilemma regarding the issue of content creation. On the one hand, designers and developers want to see as much content as possible before designing and constructing a site. Knowing exactly how long and complex a certain form is, how many product sheets there are, or what the charts, graphs and tables look like, can offer good clues for visual design, information design, and page structure. Clients, on the other hand, need to know how long the content they are providing needs to be and how it will be used in the context of the site. They might assume that certain existing brochures or information sheets might simply drop into place on the website. However, content that is reused from other sources rarely fits into a website. At the very least the content needs to be edited so that it is appropriate for the web. This dilemma sets the stage for many small miscommunications that can cause changes and delays in projects.

Prototyping allows the client and development team to mock up a site with "dummy content," but structure it in a way that will match the purpose of the final site. This allows designers to do a good job designing appropriately to content while giving enough clues to the content provider to create content that will fit the site.

Creating appropriate content is one area of difficulty and potential confusion; actually delivering the content is also a frequent problem. Clients consistently underestimate the amount of time necessary for content creation and collection. Once a prototype is in place it can become a means of coordinating and delivering content. The specifics of how a prototype can be used in this way will be covered later.


Prototyping helps to avoid miscommunication about a project's scope, or its complexity of content. If the developer, anticipating what a client might need on a particular page, mocks it up as they expect it to be, the client can then react to it. If the client expected more detail than a prototype represents, they can alert the developer and work it out. If there is less detail, a prototype can be adjusted as well. Making adjustments to a prototype is much easier at this early stage of development and can save incredible amounts of time, money and frustration later.


Prototyping does add a phase to a project's schedule. However, adding the time to create an HTML prototype does not add to the overall development schedule or budget. Prototyping doesn't take as much time as you might think. By reusing templates and keeping them simple, prototypes can be created very rapidly. Whatever time prototyping does take will ultimately save more time during other phases of a project.


In addition to saving time, prototyping also increases quality. Time spent working through prototyping generates new and better ideas.

These ideas surface while working through the prototyping process. When using typical development processes, ideas are discovered after it's too late (or costly) to make changes. The real cost savings in grayscreen prototyping is avoiding the many problems that cause budgets to skyrocket in the first place.


Prototyping not only saves the development team from wasting a lot of time and the client from frustration, it also builds trust between the two parties. While grayscreening does help to get the job done, it also improves communication, which in turn establishes positive relationships.

Hopefully the pattern is clear, that for each of aspect of grayscreen prototyping, there is a corresponding benefit that improves the relationship between a developer and client. Clients that have been educated through the prototyping process will have very few missed expectations. Most clients will appreciate how the developer has taken time to communicate clearly and comprehensively about a project. It shows them how much the developer cares about meeting their needs and getting the site right.

The prototyping process creates an upward trend in communication that establishes solid relationships. When a developer demonstrates careful attention to the needs and expectations of a client, other inadvertent miscommunications that may occur will only be minor bumps in the road. The trust and confidence built through the communication process will enable the relationship to bear any minor problems that occur. Without the prototype process, anxiety and mistrust can turn some of the same bumps into barriers that destroy a project as well as a client/developer relationship.