Information Architecture: A Rose By Any Other Name ...

By Lynn Stott

As more web practitioners have assumed the title of Information Architect to describe the work they do, and as more information architects (and user experience designers and user interface designers and information designers) are multitasking on reduced staffs, information architects have uncovered a wide range of ways to view both the practice and ourselves practicing. Unfortunately, a common response to this multiplicity has been to reiterate certain narrow definitions of information architecture, to impatiently seek consensus, and to view with suspicion those who don't fit.

The efforts to define our field and our role are understandable by-products of our economic times and of forces in our contexts of practice. However, most of us haven't paused to examine the pressures behind this quest for definition, nor have we considered the options (and potential advantages) of refusing to pigeonhole ourselves. This essay takes a moment to do both these things.
I'd like to first examine the impetus behind the pressures we feel toward narrow definition. Then, I'll suggest ways we can use insights about our diversity to fight pressures to define our work narrowly and to forge more respect for and responsiveness to the work of information architecture as a whole.

Pressures to define IA

Fervent efforts to define information architecture far outpace the evolution of the discipline in actual practice. As a group, we're attempting narrow definition before our praxis has reached its natural range and depth. However, we're not rushing to definition just for the fun of it. We're under pressure from all sides-to justify our positions, to demonstrate our value, to explain what we do and why we need to be included in projects. The pressures to define our practice and our role on web teams are varied, yet interrelated. Most fall under these main themes:

  • Current economic pressures mean there are fewer IA jobs to go around-and we're hungry;

  • We're under semantic pressure from Computer Sciences and IT to craft our roles into something that better fits known protocols;

  • Despite gains in visibility and credibility, we often find it very difficult to explain to others what we do;

  • We're involved in a bit of sibling rivalry with colleagues identifying as professionals practicing user experience design (UX), information design (ID), interaction design, and, sometimes, usability.

  • Let's take a moment to examine each of these elements more closely, to better understand the context for our drive to definition. Then we can ask whether it's really in our best interest to do so.

    1. It's an economic thing

    Business's constrictive response to recent economic uncertainties means that, for the moment, there is less work out there than there was three or four years ago. Corporate web groups have pulled the purse strings tighter and have often (wrongly) deemed the value information architecture brings to the web planning process to be luxury rather than necessity. Information architects are starting to feel panicked.

    This real threat to our livelihood is the first of many pressures information architects are feeling to define our work. With pressures to justify information architecture's return on investment (ROI) at every turn, we feel compelled to define and clarify the format and value of our deliverables, justify the time it takes to do the thinking and analysis so much of our work requires, and explain repeatedly to stakeholders why information architecture is necessary to the work of the design and development team. As a result, we're seeking to define our discipline more precisely and to demonstrate competencies and deliverables that can be measured and evaluated by all-so they'll see how we matter and will let us keep our jobs.

    But we should be cautious. Our responses frequently take the form of dogmatic entrenchment and can lean toward a potentially dangerous commodification of our work. I suggest that both these outcomes are undesired-even detrimental-to our success as a field of practice.

    2. Pressures from IT processes and roles

    The push for an easily evaluable practice and set of deliverables comes, in part, from an information technology worldview. In many corporations and in a good number of solutions firms, web planning and development has been structured under models formulated first by database development teams and information systems construction and management. In many of these models, team participants are certified or licensed in competency in particular programming languages or project management protocols. Competency is measured based on passing certification exams and deliverables are clearly defined according to the requirements of the next "client" in the work process chain. This work generally can be evaluated and, to a certain extent, duplicated, by any other similarly licensed professional-regardless of that person's work context or past experience.

    Since many managers and team members in web project design and development spring from IT backgrounds, there is a general tendency to expect the same type of standardization on web teams. And some web team roles do conform closely to more traditional IT roles. In general, programming, project management, quality assurance, and even graphic design roles are not viewed as problematic.

    However, information architecture (and related practices such as user experience design and information design) has, so far, been less fortunate in gaining wide acceptance. As many of our number have noted, IA (UX, ID) done well is, for all purposes, invisible in the final product. When a web solution goes live, decision-makers see graphic design, images, navigation elements, and text. One can view the code for all aspects of site function and presentation, but one cannot easily view the products of the information architect's effort, because they are so completely integrated into the site as a whole. For these reasons, information architecture's role in project success is often questioned by team managers and product leads, particularly by those who are under pressure regarding the costs and timelines of solutions production.

    [One persistent exception to the invisibility of information architecture is the group of IA deliverables with roots firmly in the field of library sciences. Metadata taxonomies, search term indices, and controlled vocabularies are visible artifacts and their role in simplifying database construction and search/retrieval interactions is not disputed. This is likely the reason many more "successful" attempts to define information architecture as distinct from user experience or information design are those that define it in terms of library sciences categorization and cataloging practices.]

    Read the Full Article

    * First appeared in Boxes and Arrows

    About the Author:
    Lynn Stott is an information architect and user experience consultant with a Ph.D. in anthropology and religious studies. Her IA and UX work is informed by insights and analytical processes developed in 10 years’ of instructional design, in academic work in community structures, symbols and meaning, and in studies of literature and classical rhetoric. She has developed in-house IA/UX teams in large corporations and now teaches, conducts workshops, and consults with clients in a variety of industries through her firm, Vivid Think.

    Read this newsletter at: http://www.itmanagementnews.com/2004/0608.html
    Free Newsletters
    Part of the iEntry Network
    over 4 million subscribers

    Send me relevant info on products and services.




    -- ITManagementNews is an iEntry, Inc. publication --
    iEntry, Inc. 880 Corporate Drive, Lexington, KY 40503
    2004 iEntry, Inc. All Rights Reserved Privacy Policy Legal

    archives | advertising info | news headlines | free newsletters | comments/feedback | submit article

    ITManagementNews Home Page About iEntry Article Archive News WebProWorld Forums Jayde iEntry Contact Advertise Downloads iEntry MacProNews.com NetworkNewz.com