The 69 page e-book Client vs. Developer Wars documents one web design company's struggle to formulate a rational development process:

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.

This, to me, is another indictment of dysfunctional specifications. I learned long ago that clients won't listen to what you say, and they certainly won't read what you write. You're much better off putting that wasted effort into a working model and setting it in front of the client. Let them play with it for a while. Refine the working model based on that feedback, then keep turning the crank on this cycle until you run out of resources.

And that's exactly what Eric Holter proposes in this e-book:

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.

Yet 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' exaggerated 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.

Yes, some of the advice will be old news to agilists, but give the guy a break: this was written five years ago. They call it grayscreen prototyping. I think it's a reference to the old default gray background color of Netscape 4.7x. So the implication is that we're talking about low-fidelity HTML layouts -- so basic that they don't even specify a background color.

There's nothing magical about the solution proposed here, but it's solid advice written well. Recommended. And if you're not into the whole reading thing, you can even download a 16 minute video presentation that covers the whole shebang.