I’ve been corresponding with adam, the author of the terrific article I mentioned below, “Why is usability so hard?” and I got so het up I thought I’d share:
adam writes:
And therein lies the irony. As much as usability specialist and usability engineer may be confusing, it’s nothing compared with the confusion that surrounds information architect. I suspect that you and I have similar definitions, but I’ve had people tell me that it’s an extension of library science or that it’s part of database programming, and when I look at job listings and see information architect, what they’re usually describing is someone with good, solid user interface design skills. You seem to approach it as if it were most closely related to information design, is that correct?
me:
pretty much–
you have to understand the history of the title to some degree.
Richard Saul Wurman selected the title Information Architect to describe anyone who organized information into a form that promoted human understanding. In his book, Information Architects he showed examples of this that ranged from folks who did weather maps in newspapers to website design. But what he didn’t know is the title already existed in the software world as a type of database engineer. When Lou and Peter came out with their definition in Information Architecture for the World Wide Web, it was heavily affected by their background in Library science. As former librarians, they were very good at organizing information for retrieval– the key problem in most intranets (nearly all Argus’s clients were intranets in the beginning). So their definition was filtered through their experience, just as Wurman’s was through his background as an Information Designer.
Next: a lot of companies had these two books laying around: “Information Architects” and the polar bear book–“Information Architecture for the World Wide Web” And as websites grew too big for any one person to hold it in their head, people stepped up to plan those websites out– sometimes graphic designers, sometimes usability folks, sometimes project managers, sometimes writers, sometimes engineers— all they really had in common is they looked at big websites and thought “what a mess.”
So they started organizing the websites. And in those days of strange and shifting titles, they realized they were spending all their time planning and organizing the structure of the website and no longer doing their old job, and maybe they were due a title change. And odds were high they had one of the two books on their desk, and decided that Information Architect was probably the best title for them, even if they didn’t do everything in the book, or even if they did quote a bit more. IA’s have grown up quite organically, responding to a need.
We are actually seeing some title-splintering now: new titles such as experience architect, information designer, interaction designer, content architect/strategist are showing up left and right. It is entirely possible as the job of “plan and organize website” becomes “plan and organize the interface” or “plan and organize the content” or “plan and organize the interactive behavior on the website” that the information architect will disappear much in the way webmasters are becoming more and more rare. Or Information Architect may only do one tiny part– just the content organization, perhaps. Or just create site maps.
Personally I think that would lose the greatest value the IA gives to a project. When you have nothing but specialists work on a project, you have the equivalent of blind men describing an elephant: most engineers don’t much care about business or user needs and they concentrate on how to make the code most effective. Most business people don’t fully understand the consequence of code (nor do they care) and are interested in users only as consumers, and usability folks often get so concerned with users they forget the business needs or the engineering constraints…. A good IA takes in what is possible from engineering, what is viable/profitable from business and what is desirable/necessary from the users and balances them out into a system that works.
Please note my qualifiers “most” and “a good.” I know many folks who can see beyond their discipline, and I know some IA’s who cannot. But in my experience most IA’s act as translators, going from one discipline to another to ferret out the compromises that will allow a solid system to be created. At Jesse’s talk at ASIS: “What Do You ‘DO’ All Day?” pdf we discovered most IA’s do a fair amount of requirements gathering and a chunk of project management. Mostly they don’t touch the schedules (except to complain about them, natch) but they do run back and forth trying to marry conflicting requirements. Once those compromises are reached, they document them and realize them by designing systems (site maps, content organization schemes, wire frames, conceptual models and the like) to create a blueprint for the work to be done by design and engineering.
So if they IA is whittled down into the role of “thesaurus designer” or “interface designer” who will see the big picture from a design standpoint? Who will know what the elephant looks like? On the other hand both those jobs could be full-time jobs. I wonder what the future will look like. Will be have both? Neither?