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:
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.]
3. Explaining the work we do-thinking and vapor
The work of information architecture is both creative and analytical. Our planning and production deliverables (requirements documents, profiles, wireframes, storyboards, taxonomies, flowcharts, metadata, etc.) exhibit only a distilled fraction of the idea crunching and information relationship analysis that takes place in our work. Some view our time involvement in a project with suspicion: “What do you mean it took you 20 hours to produce this 4-page document?!” What’s more, our tangible “product” is ephemeral-consumed by the production process like fuel in a combustion engine.
As I mentioned above, when our work is done well, the project is successful-users easily execute tasks, and business goals are more effectively achieved. However, what business managers actually see, when they look at a final web project, is rarely “information architecture gracefully communicated and elegantly executed.” They see the visible work performed by our colleagues in design and programming-work that embodies our work, depends on our work, but which also consumes the tangible remnants of our efforts. So, management questions our usefulness.
This pressure dovetails with a difficulty many information architects (particularly those situated outside a “library sciences” practice) face when asked to explain what we do. The truth isit depends-it ALWAYS depends. Some lucky (though, I would guess, bored) IAs may practice in contexts where projects are homogeneous enough to have developed a fully standardized process, standardized set of tasks, and standardized set of deliverables. However, it would appear that the work of a great many IAs is far from routinized.
There is, of course, a general discovery and process trajectory to be followed and each node along the information architecture process trajectory is home to a host of sub-processes and contingencies. The speed with which we move from node to node, and the selection of tasks and deliverables at each node depend on a multitude of variables associated with project scope and the roles of other participants on a given project team. When you add this layer of contextual variety to the different approaches to IA taken by its many practitioners, the idea of envisioning a standardized, clear definition of information architecture is obviously unrealistic.
How we practice IA varies from context to context, from project to project, and from practitioner to practitioner. When asked to explain what we do, we often find it easier to recount what we did on a particular project than to explain what we do in general. This is not, as some would suggest, a bad thing, for it’s by these practical examples that we succeed in clarifying what we do. But this propensity toward anecdotal explanation, however to the point, can make life difficult in contexts in search of quick answers and easy definitions.
4. That sibling rivalry (the economy again)
The final pressure to define IA more succinctly stems from what can be regarded as a sibling rivalry with our colleagues in user experience and information design (and, sometimes, in usability and interface design). All these disciplines share similar commitments to consider the users’ needs in the organization and navigation of the web site, web-based product, or application. Depending on context, these practitioners are charged with the successful execution of business and marketing goals alongside (and often in tension with) a commitment to usability and findability on a site. The truth of the matter is, we actually do a lot of the same tasks and add quite similar value to our projects, and some of us have all these responsibilities-regardless of what we call ourselves.
Due to the overlapping interests of these roles and as a response to the perception of a reduced size of the “pie” from which we are all to carve our portions, there are considerable pixels spilt over what is information architecture vs. what is user experience design vs. what is information design (and now, vs. what is interaction design). Yes, there are differences, but there are HUGE overlaps. Why do we struggle so? I would suggest that it is, in no small measure, the economy again. We are all eager to define ourselves as the ones who should be called into projects to address the juncture of task, information, navigation, and user needs. Each discipline is trying to define itself as broadly, yet concisely as possible. Each discipline wants to be THE one that makes sense to product leads and decision-makers. This drive is understandable. Times are lean. The mortgage is due. We’re getting a little hungry.
Nevertheless, the rush to define and inscribe boundaries is misguided. Defining information architecture, its practice, its deliverables, and its practitioners in any but the most general and conditional of ways will drain much vigor and value from the work we do. If we succumb to pressures to narrowly define and firmly circumscribe our practice, the breadth and depth of the source from which we draw our insights and ideas will shrink substantially, and so will our circle of influence.
I suggest that the proper response to the chorus of pressures to codify and define IA is not to succumb and start scrubbing the floors of our little pigeonholes. The best response is to reject altogether the tendency to pigeonhole.
Doing a little IA on the effort to define IA
When one looks around at the work of the folks who call themselves information architects, it soon becomes clear that information architecture is, in part, a mindset, in part, a core set of values, in part, an analytical lens, in part, a loosely grouped set of practices, and in part, a set of analytical tools and communicative deliverables. It is by no means a standardized practice whose products can be objectively assessed against a set of requirements by any other “credentialed” information architect. What we do has a large dose of informed subjectivity to it-and that’s a good thing. But the business world is very uncomfortable with “squishy” subjectivity.
Information architecture for the web is a discipline generally committed to structuring information and task flow in a manner that optimally facilitates the user’s finding information or performing tasks he or she wishes to. As a practice, information architecture moves in the interstitial spaces of the web development process-linking user tasks to business needs, linking users to information, linking functional programming to design, linking site structure to navigation, linking strategy to execution.
As a community, we write and blog into being a multilayered discourse of information architecture. Contributions to the discourse, coming from IAs with backgrounds in graphic design, library sciences, writing and editing, computer science, project management, teaching, anthropology, psychology and more create a rich field of techniques and insights from which we draw elements for building our own practices in our own contexts.
The actual manifestation of any particular information architecture practice depends more on the background of the information architect and the context in which he or she practices than upon adherence to any standardized definition. That context includes the IA’s own pre-web background, the industry in which the IA practices, the types of projects he or she works on, the roles and responsibilities of other members of the planning, design, and development team, and a host of other factors. These same factors influence whether the practitioner is called an “information architect,” a “user experience strategist,” an “interaction designer,” a “content manager,” or a “producer.”
If we look at the actual practice of information architecture as our starting point, we soon see that IA, by definition, resists precise definition. This is our reality. (If it didn’t resist definition, why else would we still be arguing about it?) If we wish our work and the value we bring to the table to be better understood and valued by colleagues, managers, and clients, we should do for our discipline the same thing we would do for a similar “difficult to categorize yet vital to many user groups” element in the organization of a website’s content.
We must create multiple access paths to our value and our work-paths crafted to appeal to and work for different sets of colleagues and clients based on their vantage point and understanding. The best way to do this is to look to our inherent diversity; the paths are already there. We need to consciously own our differences; that makes the pathways more visible-and therein lies our hope.
There are clients and managers who may only be able to see value if shown one particular pathway to understanding and not others. The diversity of background, context, and approach to information architecture that so many of the “definers” see as problematic is actually our greatest asset, for it is in our particular differences that we’ll “connect” with clients and decision-makers-not in our capacity to mold ourselves into cookie-cutter “Information Architects.” We need to claim the descriptions that best describe the work we actually do at any given moment-and we need to be flexible while we do it.
We need to meet people where they are and be willing to use their language, not always force ours on them. This applies both within our own ranks and when speaking with clients and decision makers.
For example, I was recently in a conversation with a very successful eCommerce merchant (still profitable and growing) whose site could improve mightily with a good IA/UX workover. I was explaining how I could help him, but he seemed to be stumped by my use of the terms “information architecture” and even “user experience.” (His pre-web background is software engineering). As I shifted to a discussion of the role of my analysis and my documentation in the development process, I saw the light appear in his eyes. “Ohhhh!” he said, “You do UI!” (user interface design). And, though it has never been a term I’ve used do describe my work, I could see it was the glue that put it all together for him. He understood my pitch, he “got” what I do, but his reference vocabulary was different from mine. “Yes,” I said, “You could say I do UI.”
The power of multiple access points
A major tenet that underscores many of our frustrations and spurs our compulsion to define ourselves is our desire to find ways to help stakeholders, product managers, and senior executives better understand and value what we do. The best response to these pressures is not to create a monolithic definition of information architecture, however comprehensive, but to explain the core values and commitments of IA and for each of us to share, as explicitly as possible, our own particular slants on the practice.
That way, IAs from design backgrounds can help information architecture make sense to designers, but also to marketing and communications folks who understand that language and process. IAs with backgrounds in computer sciences and database design can help information architecture make sense not only to programmers and DBAs, but to members of management who have learned “IT talk” and may be frustrated with some of the more “squishy” elements of the user-facing aspects of web and application work. IAs from the social sciences can appeal to managers and marketers who understand the language of culture, human factors, etc.
This is an important strategic move. We’ve got a message to spread about quality, cohesion, organization and usability in the web product development process. But since our clients, colleagues, and executive managers learned about IT and the web in many different ways, the ears that hear the message we share are tuned to a variety of vocabularies and metaphors. Many people won’t hear what we have to say if we always deliver our message the same way with the same words.
By consciously creating these “multiple access points” and attending to communication, education, and persuasion on these different channels to understanding the tenets of information architecture, we’ll create a higher valuing of IA in the industries in which we work and make more space for its practice in all industries. We each can reach colleagues and managers who see the world of business and product creation in ways we do (from our pre-IA experience). We must learn new vocabularies of explanation from one another and make more explicit the connections among them. By the sum of our efforts, we’ll help draw all those folks to a greater appreciation of the value of IA to the project development process and to the enterprise.
Let’s hope that our complicity with the broader effort to narrow and define information architecture’s field of practice is merely a misguided application of the information architect’s penchant to organize and categorize anything within reach. Let’s resist that urge. The key to our success is to acknowledge the reality of our rich variety of practice and perspective and to use the facets of that variety as a strength.
The more praise each of us receives, in our own contexts, under whatever label, the more the work of the discipline as a whole will be respected and valued, and ultimately, the better the web will be.
And, after all, isn’t that why we do what we do?
* First appeared in Boxes and Arrows
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.
