Why Paper Documentation Doesn't Work

I actually have a grudge against the use of paper for planning, describing and defining a website. Paper, while helpful as far as it goes, ultimately fails because it leaves too many gaps in understanding the subtle dynamics of a website. Whenever I talk about our process I always quote George Bernard Shaw who said "The biggest problem in communication is the illusion that it has taken place." Any incomplete communication process is subject to the biggest problem of all - the illusion that communication happened. We are in the most danger when we assume we've communicated. Paper prototypes give a false sense of completion. As a result we move forward with a degree of unfounded confidence, having used so much paper. But it's not until a project emerges from development, when the client can click around, that these gaps reveal themselves--usually too late for an easy fix.

No doubt a careful balance needs to be struck between being too technical and being incomplete or irrelevant. Our solution was to document the website using a website. We stared using visually generic "grayscreen" HTML prototypes. The problems of using too refined or polished a tool in the planning stage, problems highlighted in the two recent postings, were still a potential problem. But we found that as long as the prototype was intentionally gray and generic (even ugly) our clients knew that they were not dealing with a final product and that their ideas, questions, and changes were welcome.

I remember the moment when I first realized we were on to something with grayscreen prototyping - hey, why is everything getting blurry and wavy - ah yes, it's the going back in time transition, nice...