Underlying Principles of Grayscreen Prototyping

The goal of grayscreen prototyping is to effectively communicate the structure, content and functionality of a website in a way that allows all of the parties involved to understand. The preceding chapter highlighted a number of benefits to grayscreen prototyping but it is important to remember that its ultimate goal is effective communication.


Grayscreen prototypes need to be created and modified rapidly. Working through the structure, content, and functionality of a prototype will require multiple iterations, so the speed of adaptation is important to implementing the process efficiently. One of the ways to speed things up is to remember that a prototype is a working document. It does not have to be "finished" before the development team or the client can look at it for input and direction. In fact, the earlier and more frequent the input the better.

There will be many changes to a prototype as clients and developers experience a site in its prototyped state and their creative juices get flowing. In order to keep these juices flowing, modifications to the prototype need to be made quickly. The faster a prototype can move from one state to another the more the client and developer will be able to focus. Clients and developers risk losing the continuity of their thoughts as time passes between revisions. The more continuity and focus during prototyping, the better the results will be. To facilitate speed and efficiency, prototypes need to be kept simple.


The name grayscreen prototyping comes from the default gray background color. In order to revise prototypes quickly, time should not be spent making them "pretty." This means that time should not be spent formatting the display in a prototype with font styles, colors, sizes and faces. Tables and other more complicated HTML structures should be simplified and minimized. A prototype should be as generic as possible. Graphics should almost never be used in the overall "design" of a prototype. Simple text based navigation helps keep a prototype as simple as possible.

The physical location of page elements, such as the navigation bar, is not a concern of prototyping. For example, the main navigation may display on the top of the page in a prototype while the final layout may place navigation along the side. How the navigation categories are grouped and named, and what sub-categories live under them are the concerns of a prototype. Separating main navigation from sub navigation should be reflected in a prototype. Where these pieces of navigation are placed and how they'll look on the final site is not relevant. What is important is differentiating main content areas from site utilities. Things like layout, font and color choice are not.


It is very important to keep prototypes non-visual. Making sure they are organized, clean, and professional is of course important, but I have found that it's far more critical not to suggest what a site might look like prior to the visual design phase. Part of the reason for this is to keep a team and client focused on issues of a site's structure, content and functionality, not its look and feel. Introducing design elements into the prototype will only confuse people. Adding design elements such as a subtle background color or typographic treatment will only distract from the primary purpose of prototyping. Besides, a designer will ultimately want to make design decisions after a site has been defined, not before. Design suggestions made before full definition are always premature.

This is why I use the term "grayscreen" prototyping. Ideally a prototype will lack any suggestion of visual direction. A prototype should be as generic as possible. At one point I considered "designing" our prototype templates so that they would look more interesting. I quickly realized that this was a bad idea because even if "the look" was just "a prototype look" and not the intended look for a site, the opportunity for the client to confuse visual suggestions in the prototype would cause them to lose focus on the other more important issues of structure, content, and functionality.

Keeping prototypes non-visual also contributes to the speed and flexibility of their modification. As soon as graphics, backgrounds, and layouts get mixed in, a prototype becomes less flexible and more difficult to modify. If a prototype itself becomes too complicated or time consuming, its benefits will be reduced. Rather than spending time adding visual style to a prototype, time should be spent making them thorough.


Any time spent adding detail that fully describes the content and functionality of a site is extremely valuable and will save time in the end of a project. A prototype should be thorough enough that anyone reviewing it will be able to easily understand a site's structure, the nature of its content, and how it will work. If anyone is confused or unclear about any of these aspects, a prototype is not finished. Ultimately the client should understand exactly how a site will be structured, what it will contain, and how it will work.

I recommend spending as much time as is necessary to thoroughly represent a site in prototype form. Taking shortcuts or breezing through the prototyping phase will ultimately add time to a project. Incomplete prototypes will require more work later. Problems that result from miscommunication require significant time to fix. It takes much longer to rework database fields, templates, and designs after the site has been completed than it does to thoroughly work through a prototype in the first place. When a prototype becomes a thorough representation of a site, the entire design and development process is made more efficient.

Another benefit of a thorough prototype is the depth of insight it elicits. The more detail a prototype contains, the more ideas, questions, and clarifications it will invoke. This avoids costly changes at the end of a project, but also improves the final site.