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 IA’s penchant to organize and categorize anything within reach.
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.]
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 is…it 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.
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.
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.
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.
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?
I guess I’m left with two questions after reading this article:
1) If you replaced the word “information architect” and “IA” with “interface designer” and “UI” would you have the same article? If so, then why not just use those terms instead of constantly referring to the job as “IA” throughout the article?
2) I think you somewhat neglect the issues on who makes the final decisions in any design. After all, in the business world, someone has to be accountable and make the final call. The real question here, how do titles and job function also affect the decision making process on a project?
If a self-proclaimed IA has no background or training in visual design, should they make the final call on what icons, typogrpahy and color systems to use? Would you mind if a self-proclaimed UX person told you that the entire taxonomy proposed was simply wrong, when it seems quite clear they have little background or trianing in that sort of work?
I’m on mailing lists and follow blogs for information architecture, information design, usability, interaction design, user experience design, user interface and human factors. There’s a lot of confusion and obfuscation for the reasons you describe. I’d love to work in ANY of those fields, and have the experience and the philosophy, but I have to sell myself as a Perl programmer and web designer because I don’t have the raft of qualifications and certifications required (such as a PhD in cognitive psychology, which some employers have demanded).
The fact is I’ve never seen a job listing or found an opening for a strictly specialized “information architect” on the Web, except for the library-sciences positions you discuss. Maybe after 10 years working in the web business I am at too junior of a level. What I have seen in the web production chain is that the overall architecture of the site usually falls to a series of meetings between marketing and engineering. Marketing has a list of demands, legal requirements, and whims that the engineering staff is tasked to build. A few whiteboard sketches and 3×5 cards are taped up and the navigation is decided upon – without a full time architect who holds authority over that. Then when coding begins, any changes are regarded as scope creep and fought viciously by the developers and their manager.
I have found myself in positions analogous to an information architect’s many times, but never officially and never with final authority. Final authority always, always seems to rest with the VP of marketing who read an article in Fast Company that morning and now thinks the site should be blue. 🙂
Oh, BTW, there’s a bug in the MT code making it unclear when a comment has been posted, leading to the double posts. The MT-comment.cgi redirects the user to an eleganthack.com URL that comes up 404. The preview works properly but the posting is buggy.
I agree with the comments and assorted nightmarish scenarios described so far.
Gary, I think that on many jobs valuable IA contributions come from people without IA titles, like yourself. Chasing that title may be a goal that you have. I’ll get lynched here for saying this, but for 99% of web projects, I would rather have a great programmer or a great visual designer on my team who understands and does IA than some cognitive psych PhD.
As for final authority, that is a delusional concept.
I think those of us who favour a “definition of IA” are being slightly misrepresented. We’re not trying to pigeon-hole or define for the sake of defining. We’re not in a turf-war with ID/UX/whoever. We’re trying to get a broad consensous of “what it is we do” – at various levels of granularity – from “we help people find stuff” to “we use mental models and analytico-synthetic analysis to build information ontologies” (and other pretentious phrases) – so that we can appeal to all of the different audiences that the article mentions.
However – we can’t effectively do the following quote from the article:
“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.”
…. unless we all have the quoted “shared message”. Its no use having two people using different techniques to talk to two audiences about IA if one is saying that IA is all about wireframes and screen design and the other is saying IA is all about site structure and organization.
To me what is missing is not a definition of IA. I’ll stick w/ the one that AIfIA put forth on their web site, but what is really missing is what is the umbrella. There is no one working there. No one is working to create a viable unconfusing umbrella for all of us. We are so stuck in defining the particulars what we forgot is the first rule of taxonomy (what’s his name Lineus?) that you need to know your parents before you build your children, right? How do I know that a horse and cow are related to each other if I don’t even know what grouping they might share?
If you look at the conference agendas for IA Summit, UPA, CHI, and STC you see a lot of overlap, but the overlap is not contextualized, so it appears that all 4 are trying to take their respective name now mean the overlap. This to me is wrong. It dilutes the meantion and strength of the particulars and thus we loose the value of the multi-facets that Lynn so correctly wants to preserve. Experience Design at CHI looses “design”. Interaction Design at UPA becomes an attemtp to make design less subjective and more validative and quantifiable. Even if unintended, this is the outcome.
This is the real damaging piece. If in defining the particular we subsume the whole we are missing the point and we are hurting our peers’ abilities to differentiate and show value and (as you suggest) bring their particular backgrounds and contexts to bear on the whole.
I would like to take this opportunity to call on all the groups no matter how old or young they are, or how many members they may or may not have and come together to define the umbrella. Maybe even have our separate organizations become partners in a new umbrella organization. What that new umbrella is, I don’t know — User Experience (some hate the word user) … but there is an umbrella out there, eh?
I think the main problem I see with defining IA is that very few people do it exclusively, except in some mega-corporations. And even then, budgetary restrictions usually means that the IA has to wear multiple hats. Hence, I’m more concerned about defining the skill-set used in IA-work than defining the job of an IA. Certainly the jobs of interface/visual design, or user-experience testing can involve IA elements, but that doesn’t make those jobs IA, nor does IA mean those jobs either. (And in a time when job security is non-existant, the more hats that you can wear, the better off any and all of us are!)