Travis has consented to allow me to reprint his insightful email here:
“The meat of your post from Monday — where you cast about trying to arbitrarily determine whether the term “usability” should be applied to people who measure usability, or to people who create usability — I’m not even gonna touch that. (except to the extent that I just did.)
and I’m not even going to touch the word “arbitrarily”–c
But I dig your question at the end, about whether to split forces, and I have an answer for you.
Info-centered IA is basically a term I picked up from the SF IA discussion to increase the chance that you and Noel would have a sense of what I meant. Application-centered IA is probably a better moniker. So there’s that, there’s user-centered IA, and my usual answer for a third type is revenue-centered IA (you know, MBAs do it, deliberately restricting some info while exposing enough to string people along — very different from user-centric design).
My purpose in app-centered IA is to create structures for info — data records, actions, processes, whatnot — that are organized such that applications — processes — can use them well and build on them whenever necessary. The structures are never completed products, since you want them
to last, to evolve along with their applications, to be friendly to new apps. I don’t know how much this philosophy figures into user IA but it’s critical to app IA. A complete website redesign has no equivalent in a good application information structure.
All the primary applications — serial communication (e.g., encoding into XML), display (presenting in a web page), persistence (storing in a relational database), service (manipulating with program logic), etc. — define the borders of my environment as an IA. So of course I’m particularly aware of all of them, and there’s some translation that has to happen between each, but the idea is either to minimize that or to make it seamless and scalable.
Point is, I think that user IA and app IA are _very_ different, because user-centric design is all about patterns friendly to the human brain, which are exactly the kind of patterns you have to filter out if you want to be objective about app-centric design. Don’t want to disappoint you as a would-be uniter, but I bet very few people are good at both. Maybe this is why my discipline is not very well covered in the preferred media of cocktail hours and weblogs; if you really want to get into technical
information semantics you go to W3C and start reading specs. And there’s less room for speculation and rambling theorizing, which is definitely the fun and social part.
_Any_ IA is, like Adam says, a creative endeavor. Everyone wants to design _something_. Anyone with a single bit of serotonin in their brain wants to make pleasant order from chaos. Musicians organize sound. Writers organize thoughts. Software architects organize application logic. I’m sitting here
trying to organize variants of information architecture. But the fields are pretty divergent and that’s why we usually specialize in just one. To be honest, I think “usability” — or the constantly evolving acronym known as UI/UE/UX — is more specific about describing your work than is “information architecture”, which is understood by everyone you work with, but it doesn’t surprise me that “defining IA” is such a necessary topic when dealing with those outside your circle.
If you want a real bit of fun, ask a traditional architect to define “information architect”. An architect I know thought it must refer to the person who kept track of the specs for buildings. In fact, when I explained it, she was a little offended at the use of the term “architect” outside the context of buildings. Yeah, that’s a bit extreme, but you get the point.”