Last night I went to the monthly UI/IA cocktail hour, a gathering of information architects and people in associated positions or bents. We did a lot of talking about the iterative cycle and how in reality it's not "iterate, iterate, iterate" but "iterate, obliterate, iterate."

The problem tended to boil down to the perception of the web as a media, and thus any web project is something that grows stale and needs to be redone, just by virtue of it being media, like an ad campaign or a movie. Of course that's not the only problem, user needs, business goals, and functionality changes, so that the house that was build to fit the needs of the time becomes inadequate, and a house that is constantly being appended with additions becomes ungainly and difficult to navigate.

Basically, these projects shouldn't be seen as houses: when designing a project, we should realize that half the functionality will be obsolete in a year, and new functionality will be required, so designing a house isn't the best way to go. Instead, create one unifying layer, a design paradigm that sits above the functional layer, a look and feel that could be used for any number of purposes and modalities. Then, with that 'interactive style guide' in place, design functionality into modules, so that as some functionality is obsolete, it can be removed, and new modules can be brought into play, without leveling the house and 'doing it right this time.'

The main thing is to realize obsolescence is that building the 'perfect site' (or application) isn't about making a functional work that will endure through the ages (if your functional needs don't evolve over time, then you should be worrying about the stagnancy of your business more than your website), it's about creating something that can evolve bit by bit, instead of revolve every 18 months into something 'new and this time perfect.'

Of course, in a practical sense, this means abstracting content from display, in general abstracting front-ends from back-ends, and creating small, tightly focused mini-houses and shaping them into a neighborhood. Like a real neighborhood, some houses will get torn down and new ones may be built to replace them, but since they're small segments, there is never a jarring time when everyone has to learn something new.

In a sense, it reminds me of company earnings statements. Some companies always seem to show a quarter-by-quarter net profit, but only after you disregard certain 'one-time restructuring charges' which is fine, except that every quarter seems to have these charge, either because of layoffs, acquisitions, or other 'extenuating circumstances.' Similarly, if you're spending most of your development cycle waiting for those 6 months when the system perfectly maps to user and company needs (of course, those are the same 6 months when people aren't making full use of the system because they're still learning how to take best advantage of it) then you're riding a jump-and-stagnate bleeding-edge curve that keeps IAs happy, developing new metaphors, architectures, and design and evaluation processes, but at the expense of an actual usable and perpetually adaptive product. Better to drive a car and keep it on course by making minor corrections every second than to point it in a direction, let it go for a while, then see where it is when it runs out of gas, fill it up and point it again, and repeat.

Okay, enough with the metaphors, I'm late for work!