The problem with most information architects is that they come out of an academic school where the actual craft is ignored.

Sure info archs are good at taking information and structuring it, but they are horrible at thinking in actual usage, cause their goal is to make the system right rather than the experience.

So in that respect, the best results come from info archs who has a craft of some sort which normally mean they come from outside academia.

The title of IA is, like David said, just good for companies and organisations. They get it so perhaps its best left at that. We know what we do and I would like to say we are all designers of one sort or another. IA, UCD and UX are all badges that serve a purpose in boardrooms all over the world. They do their job, but we need to make sure we are not bound by them.

The fighter pilot story was an excellent way to reframe how we think of ourselves as design practitioners. The OODA model (Observe, Orient, Decide and Act)is very similar to the reflective practice model talked about by Cal Swann.

He said that ‘The design process is iterative. It can only be effective if it is a constant process of revisiting the problem, reanalysing it and synthesizing revised solutions’

In effect it is a PAOR model - Plan, Act, Observe and Reflect. Its the reflection part that is important (perhaps the differentiator to Boyd’s) that feeds into the next cycle. In reflection we evaluate and prepare to synthesis our next move.

What we also need to remember is our ability to garner tools, techniques or tricks from experience. In the fighter pilot’s situation that maybe through training or combat, in our experience it is through many different types of work.

Then we gain tacit knowledge , the ability to intuitively know when something is right and looks good. That is unquantifiable and that is what defines great designers (or fighter pilots, sports stars, dancers etc).

Of course IA is worth saving but I think we have to realise that products like the iPhone mean we need to change and adapt remarkably quickly, not rely on tried and tested techniques. Designing for emergent systems relies on tacit knowledge and no process or methodology will give you that.

Sorry for the ramble but its all interesting in terms of how this will develop

My perspective is that far from people knowing why (IA sucks at designing emergent systems), the reality is that they don’t know why; and are likely just riffing on the symptoms. The see that stuff isn’t right, but they can’t see why.

One of the things I’m really interested in figuring out over the next few years is what methods and tools IAs might/ought to use to design emergent systems. I talked with a number of people at the IA Summit this year who shared that view - possibly enough to start a decent recurring conversation on the subject.

Net: I have no clue what methods are better now, but my gut tells me we need them. My guess is we’ll see the first passes at these new tools (or modified existing tools) in the next year or so, with some consistency in the methods emerging (pun intended) in the year or two after that.

I’ve heard several people say IAs suck at IA for emergent systems, but there’s never any reason why. It’s just assumed everyone knows.

So, why are common IA methods no good for designing emergent systems, and what methods are better?