Looking for more? My book The Elements of User Experience puts information architecture and interaction design in context for beginners and experts alike. You can now order the book from Amazon.com.
29 Jan - 5 Mar 2002
Jesse James Garrett
(contact)
Translations of this document are also available:
Plus there's a handy Palm version for reading on the go (thanks to Andrew Hinton).
There is a discipline, known as information architecture; and there is a role, known as the information architect. They have developed more or less hand in hand, and up to now any discussion of one has involved discussion of the other. But now that may have to change.
There's never an appropriate moment for an economic downturn, but for the information architecture community, the recent shift has been particularly ill-timed. Just as we were beginning to make some headway in making the case for the value of our contribution to the 'Web design' process, economic pressures are forcing us to evangelize ourselves even more vigorously, as we face heightened skepticism from clients pressured by economic circumstances and weary from five years of dot-com snake oil sales pitches.
At the height of the New Economy, some among us even entertained the notion that our work would be recognized in the business community as so essential to the success of any enterprise that responsibility for these issues would inevitably reside at the top level of the organization (the fabled and illusory 'CXO'). Now, with the advent of the downturn, both the discipline and the role feel as if they are threatened with extinction.
Our response has been to close ranks and attempt to formulate a sales pitch and business rationale for our work. But we aren't really sure what we're selling. Are we selling the idea of information architecture, or the idea of the information architect? Out of this confusion, we've become mired in an endless back-and-forth regarding how we define the discipline and the role.
One school of thought tries to define the discipline based on the role. The thinking seems to be: "I'm an information architect; therefore, whatever I do is information architecture."
Definitions based upon the role tend to creep naturally toward broadness. Because the responsibilities that correspond to the role vary so greatly from organization to organization, the definition of the role (and thus the discipline) grows larger and larger. This formulation leads to the so-called 'big IA' -- a definition encompassing a broad range of responsibilities, including business strategy, information design, user research, interaction design, requirements gathering... the list seems to go on and on.
The opposing approach is to define the role based on the discipline. Whatever the field of information architecture is, an information architect is the person who specializes in it.
These definitions tend to creep naturally toward narrowness. In order to speak meaningfully about information architecture problems and their solutions, we must define the scope of those problems in very concrete ways.
The result of this is 'little IA' -- narrowly focused on content organization and the structure of information spaces. But when this definition (intended for the discipline) is applied to the role, it creates for some the fear of being 'boxed in', trapped in a role so narrowly defined that many of the elements essential to the success of any given architecture are outside the control or influence of the architect.
The expansion of the role of the information architect may well be working to the benefit of the individual filling that role (though perhaps less so since the beginning of the downturn), but it is almost certainly working to the detriment of the discipline as a whole. Citing the holistic nature of information architecture work, some people clearly won't be satisfied until they have direct control over every aspect of the business that might affect the architecture. This way of thinking smacks of the worst kind of arrogance and undermines every effort to convince businesses of the value of the discipline. The more power you try to demand, the more difficult it is to convince others to let you have it.
It has become difficult for many in the community to engage in this discussion in a dispassionate way. Any talk of defining the role inevitably threatens someone's sense of identity -- if the role ends up being defined in a way that differs from my job description, does that mean I'm not an IA anymore? Or worse, that I'm a pretender?
As a result, we end up going round in circles, with one person's definition of the discipline clashing with another's definition of the role, and vice versa. We aren't getting anywhere with either definition.
Any definition broad enough to encompass the role is too broad to foster useful discussion of the discipline; any definition narrow enough for the discipline is too narrow for the role. We seem to be at an impasse. Basing either definition on the other means one is going to be insufficient. Trying to do both at once isn't working, producing a classic chicken-and-egg problem.
The only solution is to decouple the definition of the discipline from the definition of the role entirely. Counterintuitive as it may seem, this is perfectly reasonable, and not without precedent in other fields. The conductor of an orchestra, for example, has a wide range of creative and managerial responsibilities; 'conducting', while certainly part of his job, doesn't begin capture the full range of those duties.
We face a towering array of real creative challenges, but instead we chase our tails for months on end trying to define basic terms. Defining the discipline in ever-broader terms does not advance our understanding of these challenges. Choosing a narrow definition for the discipline allows us to describe a particular set of problems with precision. And such precision of expression is absolutely required for any discipline to progress.
The role, meanwhile, will take care of itself. Organizations will continue to do what they have always done, defining roles as needed and allocating resources where they produce results.
There is another, more practical reason to divorce discussion of the discipline from discussion of the role. It may very well be that, in order to preserve the idea of the discipline of information architecture, we must abandon the idea of the role of information architect.
Information architecture encompasses a wide range of problems. But regardless of the specific context or objectives of a given information architecture project, our concern is always with creating structures to facilitate effective communication. This notion is the core of our discipline.
My background is in what our industry calls "content development", an area known to the rest of the world as "writing and editing". For some reason, not many of us have made the transition from that world to the world of IA, and I often find myself having to explain the connection.
Throughout human history, the people most concerned with effective communication have been those who worked with language. Predating hypertext, predating plain old text itself, language is the original toolkit for "architecting information".
When most people think of the job of being an editor, I think they imagine someone hunched over a desk, red pen in hand, marking up an endless stream of text, cleaning up split infinitives and dangling participles and the like. But the editorial role and the editorial discipline are two very different things. While there are definitely some people who specialize in this sort of work, there's usually much more to being an editor.
In the broadest sense, an editor's job is to help writers make their writing more effective. This involves grammar and punctuation and word choice, sure, but a huge part of any editor's job has to do with creating effective structures. An editor might be responsible for structures at many scales, from the encyclopedia down to the textbook down to the article down to the paragraph down to the sentence.
Like the editor, the information architect is concerned most fundamentally with creating information structures. But the discipline of information architecture views this responsibility in a very different light. In the world of information architecture, all structural challenges are currently viewed as variants of the same problem -- the problem of information retrieval.
The editorial discipline has to contend with information retrieval problems as well. Many publications are structured to facilitate information retrieval: phone books, dictionaries, atlases. These, however, make up only a fraction of the incalculable volume of material published every year.
All those other publications (the ones that aren't dictionaries or atlases) have structures, too. But those structures may not reflect the orderly classification schemes one would expect in a reference work. Writers and editors use structure to achieve a variety of goals. Some structures are intended to teach; others to inform; still others to persuade.
I believe information architecture can also address this broader set of problems, and that this potential is already latent in the discipline as it is now practiced. I believe that the field of information architecture will eventually reach beyond the sphere of information retrieval. But our current approach will not be sufficient to bring information architecture to its fullest potential.
If you asked an editor at a magazine or a newspaper if the structure of her product had been tested with readers before its publication, she would laugh at you. To her, developing effective structures is a matter of exercising her professional judgment -- judgment honed through years of trial and error and hard-won experience with her craft.
To her, the proof of her effectiveness in her discipline is her ability to exercise that judgment. To her, that judgment is the very reason for the existence of her role. To her, the idea of abandoning that professional judgment and recasting her role as a conduit through which research findings become structures would be simply absurd.
And you know what? She's right.
In the minds of many outside our discipline, 'information architecture' has already become synonymous with 'usability'. It is easy to understand why practitioners in a discipline as new as ours might want to align themselves with an established one that already has made some progress in establishing its credibility. But by fusing information architecture with research, we risk corrupting our process and undermining the very credibility we seek.
The current fashion in thinking about information architecture is that the only good architecture is one that has been built upon a foundation of pre-design user research, and validated with a subsequent round of user testing. But the conflation of architecture with research -- and the conclusion that one cannot exist without the other -- is a deceptive oversimplification.
At best, we are merely deceiving our clients. At worst, we are also deceiving ourselves.
Embedding our architectural decisions in research has the effect of 'bulletproofing' them. It's a lot easier to defend science than it is to defend opinion, even when that opinion is informed by experience and professional judgment. But what's going on here is not really science at all -- it's pseudoscience. Dressing our opinions in the trappings of research does not make them scientific, just as dressing up in lab coats does not make us scientists.
Research benefits architecture most when it seeks to define the problem we must solve. Research benefits architecture least -- and can actually produce bad results -- when it seeks to define the solution itself.
It's not always easy to tell whether a research study defines the problem or defines a solution. During the research process, well-intentioned attempts to articulate the problem can turn into suggestions for solutions -- especially when the person conducting the research is also responsible for creating the solution.
The structure of a research study can itself imply a certain solution. Similarly, the process of analyzing research data to produce findings can introduce biases and assumptions that dictate a given solution. And because these studies are conducted in the absence of peer review, flawed methods and biased findings never come to light.
Even worse than a research study that implicitly suggests a solution is a study explicitly designed to provide one. "The users told us how to organize the information -- now implement it!"
Research can be extremely useful in cases where user goals can be clearly identified and measured. Information retrieval is one area where this is the case; e-commerce is another. But research is ill-equipped to account for goals outside these narrow domains.
Even the best-designed research study cannot substitute for a skilled architect. The entire purpose of a research-derived architecture is that nothing ever surprises the user. Research is perfect for creating architectures in which everything is predictable and familiar. In certain cases, like information retrieval and e-commerce, that's exactly what we want.
But in many cases, the architecture must accommodate an audience unfamiliar with the subject matter. And sometimes, such as when the goal of the architecture is to educate or persuade its audience, the element of surprise can be one of the architect's most effective tools. But an architecture derived directly from research ensures that no such surprises will ever happen.
Furthermore, we might never discover these new architectural approaches if we rely too heavily on user testing as the primary means of validating our work.
When I was in high school, I took a course that was ostensibly about language and vocabulary skills. On the first day of class, I discovered that the class was actually about beating the SAT, the standardized test that is one of the keys to getting into college.
We did not learn general principles for improving our use of the language, or our command of vocabulary. What we did learn, and were drilled upon repeatedly, was how the SAT test works, how the questions are formulated, and how to guess effectively when we didn't know the answer. But beating the test is not the same thing as knowing the material.
It's the same with usability. When we hold the test up as the ultimate determinant of success or failure, we encourage specialization in beating the test. The unwritten law of usability is that the most efficient approach is the best. But again, outside the limited area in which user tasks can be readily identified and goals readily recognized, efficiency is not necessarily a universal good. Testing cannot account for all the possible goals of an architecture or its users.
If our discipline continues to develop along its current course, we will have developed an entire body of knowledge about information architecture that amounts to little more than a set of tips and tricks for beating the test. Meanwhile, the real creative problems inherent in our work will remain as poorly understood as they are today.
There is a certain type of message commonly seen on mailing lists devoted to information architecture. It goes something like this:
"I need some help. I have proposed a solution that everyone on this list would agree is completely sensible. But somebody else in my organization prefers another solution, which everyone on this list would agree is utterly unworkable. Does anyone know of any research that proves I am right?"
The real problem here isn't a lack of data -- it's a lack of credibility. The humiliation of the information architect is ongoing. First we have to explain what we do. Then we have to explain why it's important. Then, once they understand that part, our clients decide that they can do it too. After all, anything of such profound strategic importance shouldn't be left to anyone but an executive, right?
In our effort to bridge the credibility gap, we have turned to research to back up our recommendations. Our impatience with our own ability to develop a sense of what works best in the new medium -- combined with our need to persuade those who do not understand our field -- has led to an over-dependence upon research to tell us what to think.
The perceived effectiveness of this approach has led us to attempt to 'scientificize' the rest of what we do, distilling information architecture into a simple formula, a step-by-step process, a set of rules. Many attempts have been made to codify an information architecture process. The expectation seems to be that somehow we can arrive at a standard approach in which research data is fed into one end and the ideal architecture is extruded from the other.
But every attempt at articulating an information architecture methodology looks the same: great volumes of information on preliminary user research methods, followed by exhaustive catalogs of usability testing techniques. But wait -- isn't there something missing here? When does the architecture work actually take place?
The whole matter is rather reminiscent of a famous Sidney Harris cartoon, in which one scientist is evaluating another's work on a blackboard. He points out a part of the equation and says, "I think you should be more explicit here in step two." The problematic part of the equation is where the math trails off into the phrase "then a miracle occurs..."
In the case of IA, the "miracle" is the creation of the architecture itself. There is an ever-increasing body of knowledge about the research that can inform this creative process; likewise, there is an established set of methods for evaluating the results of this process. But the process itself -- the core of our work -- remains a mystery, a gaping hole in our understanding of the discipline of information architecture.
We spend all our time talking about everything except the most important piece of what we do. Ironically, our emphasis on research methods, intended to enhance our credibility, only detracts from it. The impression we create is that anyone armed with the "Seven Steps to Successful IA!" can do our jobs. No wonder it feels as if the role is in jeopardy.
Any method that does not address the creative process is woefully incomplete. Furthermore, if we continue to advocate any approach that relies upon extensive research as the One True Methodology, we risk alienating and excluding the very people whose participation we need to ensure the growth of the discipline.
Specialization, it has been said, is for insects.
But it was specialization that really helped the discipline of information architecture come into its own during the early days of the Web. And even now, it is the specialists who keep the discipline alive in the face of industry sloughing off the extra Web development staff it took on during the New Economy boom days.
Every field undergoes reversals like the present one. The challenge for practitioners is to eschew strategies that meet short-term needs at the expense of the long-term growth of the field.
Our response to current economic conditions has been to dig in our heels, insisting upon the strategic importance of IA specialists to businesses. This approach may well keep some of us ensconced in those specialist positions for a while longer. But emphasizing specialization may hinder the progress of the discipline, and squander whatever momentum remains from the gold rush.
Even though the market for the discipline will continue to increase in the years to come, the market for the (specialized) role will always remain just a small slice of that larger market.
Specialists will always have a part to play. Some organizations have so much ongoing work that having an in-house information architect will be critical to their success. Some organizations that don't usually need dedicated IA resources will sometimes have projects large enough or important enough to warrant bringing in an IA specialist to consult. Organizations whose web sites help them make money (rather than save it) will readily see the value in developing IA expertise.
But most people who do IA will never be able to focus on it exclusively. Most organizations will never have the volume of work to justify hiring a dedicated in-house IA. For the vast majority of organizations, Web work will always be a cost center, not a profit center. As a result, most teams will always be undertrained, understaffed, and constrained by budgets.
If we are very lucky, responsibility for information architecture will be assigned to someone on these teams. These people may have titles like 'Web designer' or 'content editor' or 'project manager'. For all of them, the user experience is just one of a number of issues they must address. And the work they do will constitute the vast majority of the IA on the Web.
The future of information architecture is in their hands, not ours.
The progress of the discipline depends on the development and iteration of a body of knowledge. This body of knowledge, in turn, can only come about through deliberate consideration of a wide range of architectural problems and potential solutions. What we need most of all are good test cases, and the insights that come from tackling them first-hand.
But as specialists, we have limited resources for such an endeavor. How many projects can a single specialist take on in a year? Certainly no more than a dozen, and in most cases probably far fewer. Meanwhile, for every specialist, many more non-specialists are out there working in isolation, repeating each other's mistakes, and sharing what they've learned with no one.
In order for the discipline to progress, we must open the dialogue to include these non-specialists, to allow them to contribute to the development of our body of knowledge. But this, in turn, requires us to acknowledge that the discipline and the role are separate, and that the discipline can be practiced by those in a wide variety of roles.
In addition, we must do what we can to support the non-specialists in the IA work they do. Extensive research methodologies won't help them, because they have neither the resources nor the support to implement such approaches. And even if they did, mastery of research and testing will not make a bad architect into a good one. Something more is required.
I have often been asked the secret of my success as an information architect. Here, I will reveal for the first time that secret.
I have hunches.
Of course, it's not enough merely to have hunches. They have to be good hunches. My hunches have to be better than the hunches my clients have -- that's why they hire me.
I attribute the quality of my guesswork to my training in journalism. But I'm not suggesting that every information architect attend journalism school, or take an internship with the local paper. What is needed is a new approach, not tethered to any older discipline.
Everybody's looking for the secret formula that will eliminate the guesswork from information architecture. But guesswork is an inescapable part of our work. More importantly, the quality of guesswork is what differentiates a good architect from a bad one.
This is not to say there is no place for research in the information architecture process. Research can help us improve our hunches. But research should inform our professional judgment, not substitute for it.
The perfect research methodology, rooted in authoritative scientific principles of ethnographic study, contextual inquiry, and human factors testing, will do no good whatsoever for the legions of non-specialists who will be solving the majority of information architecture problems. What these people need most of all are tools and techniques to help them improve the quality of their guesswork -- to help them have better hunches.
IA practitioners come from a wide range of backgrounds, and bring a wide range of experiences to bear on architecture problems. But despite all our differences, there is one thing we all agree on: the world needs better architectures.
Research data and formalized methodologies don't guarantee better architectures. Better architects guarantee better architectures. But nothing we are doing right now will lead to a generation of better architects.
If we continue to work from a definition of information architecture that requires that it be performed by a specialist, the discipline will stagnate and founder. Currently, we are building a body of knowledge whose basic requirements -- a dedicated specialist, extensive time and money devoted to research -- automatically exclude the vast majority of real-world cases. Such an approach will doom the specialists to increasing irrelevance as we grow further and further disconnected from the way real architecture happens.
Like the magazine editor, tomorrow's architect doesn't have the luxury of weeks upon weeks to iteratively design and test a solution. They need immediate results. They need better hunches. We, as a community with a vital interest in sustaining the discipline, should be helping them develop the skills that will give them those better hunches. Tools for thinking, not secret formulas. Skills, not rules.
To create tools that can be widely applied, we must develop a deeper understanding of the creative thinking involved in our work. Then, having provided those tools, we must also provide ways for non-specialists to join our ranks -- again, emphasizing demonstrable skills over knowledge of methods. These people will be the most fertile source of new thinking in our field, and we must cultivate their participation.
Businesses -- the decision-makers by whose consent our discipline is practiced at all -- have stumbled off the rollercoaster of the New Economy and are feeling a little queasy. They've had too many people offer them snake oil as a curative tonic.
This presents us with a unique opportunity. The choices we make now will shape the perception of our field and the directions available to us in the future.
The right message, one that is honest and compelling, will bring us the credibility we seek and the respect we deserve. The wrong message -- one that emphasizes pseudoscience over applied professional judgment, or seeks to tell executives how to run their companies -- will only lead to continuing frustration.
The message we should be sending is this one:
Information architecture is a discipline that can be practiced by people in a wide variety of roles. Architectures can be designed to achieve a wide variety of goals, not just information retrieval. The single most important factor in the success of an architecture is the skill of its creator. This skill is applied through a combination of experienced professional judgment, thoughtful consideration of research findings, and disciplined creativity. This skill can be developed and applied by specialists and non-specialists alike.
Only by being honest with ourselves about what makes us valuable can we convince others of that value. Only by being generous with our knowledge can we reap all of its benefits. And only by creating a culture in which these principles are fully embraced can we foster the growth of our field, and ensure our continued success.