The first user interface projects I worked on were all about the spec. This was about 15 years ago, before the web became the Web, before the dot coms. The approach to software development started and ended with a thick specification document. Because there was a correlation between the thickness of the document and price tag — the price being derived from the number of features listed — software companies were motivated to be in the business of creating these documents.

I can remember sitting in rooms with the business owner and the software developer, trying to understand the goal of the application. What was it fundamentally supposed to do? What did users want it to do? What would make it compelling enough to use? I became frustrated with the process. To me, you could write a 100,000 page-book about a chair, and still not know what it looks like. I was swimming upstream. The software developers would refuse to write a line of code before the spec was complete, and they were complete when they got to the last page of the spec.

I know that software developers don’t need or want to work this way. I know, I lived with several software engineers while at Carnegie Mellon. I found some of their assignments fascinating — for example, how to write the fewest lines of code to accomplish the same task. Higher grades were given for creativity and economy. Almost like poetry. Surely this is not the kind of thinking that leads to big spec docs. Clearly these documents had come from somewhere else, from the business need of scope management, to justify a price, to create a legal agreement.

I found it difficult to produce good results with this process. It was completely contrary to my experience with iterative prototyping we learned in design school, and the value of continual re-evaluation as a means to derive product quality. The rise and fall of the dot coms did nothing initially to change it. In fact, as websites became a household word and the bottom fell out of the new high tech market, web developers became even more obsessive about these specs.

New forms of documentation and deliverables emerged as communication technology opportunities continued to expand. In recent years, much excitement has been building around agile development processes. And with it, the previous process, now referred to as a waterfall development, is considered old school. Agile development is now being trumpeted as a new reality, popularized by “Web 2.0” leaders 37signals, Flickr, Twitter, and many others, including our good friends and client, Spout.com.

While this new process is more to my liking, there still must be checks and balances. My partner Yang likes to call iterative prototyping “design calisthenics” — keeping your prototyping muscles in shape. Too much of agile development offers an excuse for acting without a plan.

Planning — clarity about the objective of the tool — is essential, and the relatively new field of Information Architecture is one of the streams of thought and documentation that proves to be useful — by documenting simply the needs, context, and content of the tool. How to translate business and user needs into an artifact. Sounds like design to me.

Don’t get me wrong, there is often a time and place for specification documents. Builders need a plan. And it’s clear that the conditions under which software is being developed are changing. The speed and ease of developing software have never been better, and there appears to be an increased risk tolerance by some businesses (note the emergence of the public beta). Increasingly, startups are willing to explore non-commercial territory in the hopes of “monetizing” any popularity or site traffic ex post facto.

The demands of people and business increase at the same pace. I don’t think I’m alone in wondering if the 37signals products can hold up as their scope broadens. The next generation of Information Architecture Planning may need to include tools that allow for even faster prototyping by people with fewer technical skills. An optimal state is where designers, programmers and owners aren’t waiting for each other to innovate, but can innovate in the same place at the same time. Or as close to it as humanly possible. The best work comes from this kind of convergence.