Years ago, the Excel team was trying to figure out if it would be a good idea to allow users to drag and drop cells using the mouse. They had a couple of interns “whip up a prototype” suitable for usability testing, using the cutting edge Visual Basic 1.0. Building the prototype took all summer, because it had to duplicate so much of Excel’s real functionality or you couldn’t do a real usability test.

The conclusion of the usability test? Yes, it was a good feature! The programmer in charge spent maybe a week and completely implemented the drag and drop feature. The joke is, of course, that the whole point of creating a prototype is to “save time.”

A year later, another top-secret Microsoft team built a complete prototype for a new user interface using the cutting edge product Asymetrix Toolbook (good lord, it’s hard to believe that thing survived). This prototype took something like a year to build. The real product: Microsoft Bob, the PCjr of the software world. Another wasted prototype.

I’ve basically given up on software prototypes. If the prototype can do everything the product can do, it might as well be the product, and if it can’t, it’s not much use. Luckily, there’s a much better idea: paper prototypes, which neatly solve this problem and the iceberg problem in one fell swoop. Even luckier, Carolyn Snyder has just written a great new book, Paper Prototyping, on the subject. This is an essential reference for anyone designing user interfaces, and it’s well written to boot.