A Layer Model for the IA Profession

In the age-old struggle to define Information Architecture, many have insisted that it’s important to separate the role from the tasks, or even the role from the “title” of “Information Architect.” I strongly agree.

But as I thought about it more, I realized there was more definition necessary. We need to figure out how these things like methodologies, responsibilities, roles, titles and disciplines all actually relate to one another, so we’re all walking around on the same cognitive map.

So, in the interest of clarity, I’m proposing a model of sorts for the “what we do” part of Information Architecture.

I’ll describe the model, then discuss how it may illustrate what is really going on in our collective yearning to define (or not) IA.

Here’s a figure — please see the description below.

ialayers448

Here I am separating out “Activity” and “Practice” and “Discipline” in the same way that it’s broken down in the “25 Theses“:

23. Information architecture acknowledges that this practice is bigger than any single methodology, tool or perspective.
24. Information architecture is first an act, then a practice, then a discipline.
25. Sharing the practice grows the discipline, and makes it stronger.

Activities

By “act” I refer to the methodologies, tools, whatever. These are all acts, or in this model, they are “activities.”

Activities are agnostic. They aren’t necessarily related to any particular discipline or even any particular practice. Just as a hand saw isn’t only for housebuilding — it can be used for all kinds of other woodwork.

Let’s take a common task used by IAs: Card Sorting. Card sorting was invented at some point by someone so that they could better understand how people organized categories and labels. It’s not an inherently “Information Architecture” activity any more than the screwdriver is an “auto repair” tool.

“But surely,” you may say, “a saw is always a tool for cutting wood! It’s not useful for, say, nailing things.” Absolutely. There is always some boundary around the usefulness of any tool (i.e. activity). Let’s say, then, that in this analogy, the saw is like card sorting, and all of woodwork is equivalent to “design.” Saws get used in all sorts of places within woodwork. It’s very important both to the housebuilder and the shipbuilder, for instance. Someone who does both relates it to whichever one happens to be the current context of need.

Keep this in mind: “Context of Need.” The tool was certainly invented for some context, but it’s often useful in many other contexts. The context of need becomes important for what we mean by “Practice.”

An important point: just because a particular discipline or practice (we’ll define them shortly) happened to *invent* a particular activity, that doesn’t mean that the activity is forever and always inherently defined by that discipline or practice.

Caveat: I’m going to keep running with this saw, carpentry metaphor, and I’m going to do it in a very simplistic parable-like sort of way. Just know that I’m aware I’m probably getting the anthropological history or whatnot completely wrong, and go along with the fun ok?
[Edited to add: I'm not trying to draw an exact analogy between housebuilding and IA -- I realize now that it may sound that way. It's just a simplified example of how tool use and practice and discipline relate to one another. I *do* think that IA and traditional architecture are very similar in abstract ... but that's not the point I was trying to make with this analogy.] Thanks!

Practice

A Practice is essentially a pattern of use. As people coalesce around a shared context of need — shared goals and situational problems to solve — they share ideas and methods and tools.

Long ago when someone wanted to stop living in caves, she decided “hey, that tree over there might make a nice shelter, if I could cut it down and make it into one!” So she figured out a way to do that, and started cutting down trees and shaping the wood, figuring it out as she went. Others who were making their own shelters figured out newer or better tools and methods for cutting the tree down, removing bark, tying them together. They shared these tools and methods, improved them, taught them.

A practice is emerges bottom-up: individuals working as a collective group discover that they have similar contexts of need (a shelter) and, being social organisms, share their expertise and labor.

Community of Practice (CoP) was coined and seminally described by Jean Lave and Etienne Wenger (see Wikipedia article; see historical description). These aren’t created explicitly by any governing body or expert or guru. They just happen, because people want to learn and socially connect based on their particular context of need — their work or hobby or whatever. There is a great deal to learn about the “communities of practice” as an idea in knowledge management, learning studies, etc, but I’m not going to get into that here (but if you haven’t read about it, you should … it’s terrific stuff and I think essential for any IA).

To bring us back to our saw, then … eventually people who were making stuff with wood developed even more sophisticated tools. They relied, in fact, on whole other communities of practice — such as metal workers. It took a blacksmith to create a workable saw (Hopefully the first carpenter to use a saw for carpentry didn’t suddenly declare blacksmithing “dead.” Because that would have been, of course, absurd.)

At any rate, the saw was a pretty sophisticated tool. But it still wasn’t exclusively a “house building” tool, it was used for ship building and other stuff too. However, the community of practice around house building enabled house builders to teach one another the best ways of using the tool — what sorts of wood could take what sorts of saws, what sort of tooth pattern was best for what grain, etc. Many of these issues are peculiar to house building and required tacit and explicit knowledge to be shared about the nuances of saw use for those very particular contexts — different nuances than are required in making ships and other wooden things. The expertise became important enough that people were willing to pay those who were really good at making houses to make houses for them as customers!

At this point, it became a Profession.

Note that in this situation the Profession did not require a Discipline. Professions can be just as loosey-goosey and bottom-up as communities of practice. They don’t necessarily have to have any authority to define them outside of the collective understanding of a given society that a bunch of people make money for working in a generally similar Context of Need.

Another interesting thing about a Community of Practice is that there is no necessary or completely authoritative role or structure. That isn’t to say that there is *no* authority and *no* structure! Usually some structure is necessary just so people can meet (“Let’s meet at the pub on Tuesdays and talk about housebuilding!” or even “Hey when we meet at the pub what you say we focus on building decks this week?”) In terms of authority, there is typically an informal pecking order, a meritocracy of sorts, where people tend to acknowledge who is an expert in what. Certain people have been at it longer, or have more charisma, or are simply louder. These things may even be written down and talked about explicitly. But at heart, they’re tacit and fluid within the community.

Before I get to the “Discipline” portion, let me go ahead and say: I think that we — meaning those who call themselves “people who do a lot of stuff we collectively refer to as information architecture” –are (as a whole) hovering in the blue “Practice” area, or even just below it. That is, we have found one another, and we’re sharing tools and methods for very similar purposes and contexts of need. Some of us are more focused on the Activities (seeing IA as “expert saw usage” as opposed to housebuilding) than on the larger Practice, but most of our leadership seems to understand that there is *some* common and shared Context of Need which drives us, making the sum of all our Activities larger than its the parts.

And for us, it’s especially tricky, partly due to the nature of digital information and the incredible rapidity of change, our contexts are shifting and evolving quickly under our feet. Whereas the carpenters of old had solid wood to deal with that didn’t change from one generation to the next, we’re dealing with stuff that isn’t physical, that’s full of semantic quirkiness, in a technological context that has new inventions and innovations every day. It’s making it especially hard for us to even *describe* where the boundaries are for our community of practice, much less *define* any boundaries. (This distinction between description and definition is important for the next layer — the Discipline.)

Discipline

A Discipline is not bottom-up but top-down. Whereas a community of practice is very horizontal and peer-to-peer, with some informally acknowledged variations in authority and structure, a discipline’s very purpose is to create centralized authority of some kind.

Why make a discipline? I’d say it’s mainly for things like legitimacy and authority in the larger world.

Eventually our housebuilders (saws and other tools in hand!) realized that some housebuilders were competing with them who weren’t qualified, and were making their profession look bad. Or for that matter, when they’d try to collaborate on projects, they were making things so differently that they couldn’t fit walls and joists together well. To keep their profession from losing its integrity, they decided they should figure out who the responsible and capable housebuilders were and tell everybody “here’s the list of housebuilders whom you can trust.” That’s licensing. They also figured out some standards for how to make stuff so it would work together better.

But to do this, they had to agree to a top-down structure of explicit rules and regulations. The trade-off was significant, though. It helped business, and it helped their community of practice by establishing norms and standards, which developed into best practices and “standard stuff you should know,” i.e. curricula for training.

Therefore, the Discipline does not merely *describe* what the Practice is doing. It *defines* what the Practice *should* be doing. (As denoted in the visual model by the brackets around the Practice.)

So, does that mean that once you have a Discipline, the Practice isn’t necessary? Does one destroy the other? Absolutely not. While they may have different, even opposite, qualities, they can often work to be very complementary to one another. In fact, disciplines that really thrive and grow are highly responsive to their communities of practice.

Medicine was a Practice before it was a Discipline. But it was a Discipline for a very long time — its standards have been defined for long stretches of time without being fundamentally changed. It was a Discipline even before germ theory hit the scene, and it resisted germ theory at first! But that discovery changed everything in medical science, and radically shifted what medicine was about. Some say genetic science may do the same thing again.

There is certainly tension. Even the healthiest Discipline/Practice relationships have friction, because by definition a standard is static and resists change long enough to be useful, and agreed upon over time. Communities of practice thrive on the fluidity and collective tacit intelligence of their members, while Disciplines refer to explicit, documented “known truths.” This is an oversimplification, but it describes where they are on the continuum.

This part is important: The Activities are agnostic — they don’t care about context as long as they’re useful in whatever context they’re employed in.

The Practice, however, is *very* concerned with context. It doesn’t exist because of the Activities (the tools and methods), but because of the Context of Need.

Therefore, to describe any Practice, one must articulate the Context of Need that brought it into being, that made it necessary enough for people to coalesce and share their expertise.

For housebuilders, they can point to shelters and say “we needed shelters, so we made these things called houses, and we started getting really good at it by working together and sharing our expertise.”

The Discipline is another layer that doesn’t merely *describe* what has already come into shape — it *defines* what is authoritative, what is standard, what is legitimate.

So what does this mean for Information Architecture?

I think we’re currently in the awkward growing pains of a Community of Practice that yearns for more legitimacy, more resources, more authority and definition. As individuals, we want these things in widely varying degrees. But collectively, it’s impossible to deny that this Community of Practice wants more.

At the same time, we’re a prickly bunch. We didn’t get into what we do because we like other people to label things *for us!* We like to do it ourselves, and make lots of tidy semantic sense out of it.

We aren’t going to get anywhere further unless we can separate the Activities from the Practice. That means coming to some agreed description of our Practice. And that means *agreeing on a shared Context of Need.*

Here’s another very important point: We cannot agree on a DEFINITION until we at least have some agreement on a DESCRIPTION.

And we cannot have a Discipline unless we can agree on definition (which, as just stated, depends on having a description to begin with.)

In addition: We need to stop getting confused between Profession, Discipline, Practice and Activity. Just because we’re getting paid to do something doesn’t mean that defines the Practice or a Discipline. For that matter, just because there are some University majors and courses with “Information Architecture” listed in their titles, it doesn’t mean that we’re any closer to having a real, defined Discipline. It just means that our Community of Practice is becoming more “professional.”

So why can’t we just do that?

Several reasons I can think of (and there are certainly more):

1. We can’t seem to agree on our Context of Need. (I’ll get to this one in a bit.)

2. Unlike our friendly housebuilders, we can’t point at a shelter and say “we make that!” We don’t make things with walls, we make things with relevance. If we do our job well, it’s invisible. It’s very hard to prove a negative, or describe a Discipline with one. This is a serious challenge that we have to tackle. We have to figure out how to point at what we’ve done and say “We made that” — because right now when we do that, interaction designers and usability folks say “um, hey, you’re pointing at an interface.”

3. There are tensions, mostly healthy ones I think, between the bottom-upness of our Practice and the top-downness of the Definition/Discipline that we’re collectively looking for. These should improve with time … conventions and shared understanding will eventually happen. These things cannot be rushed or forced artificially. They can be helped along, though, I would imagine.

As I said, there are probably other reasons.

I’m not saying that all Communities of Practice *have* to eventually become Disciplines. Hip Hop artists are doing quite well, thank you, without getting an MFA in hip-hop. Though I’m sure that’s not far off.

But I am saying that it will be hard for our Community of Practice to evolve further without being able to agree on our description — which hinges on our Context of Need.

And it will be *impossible* to have a Discipline without it.

So what is our Context of Need then?

It may seem obvious, but evidently there’s a lot of disagreement.

Until this point, the model I’ve proposed is pretty neutral. The model, I think, works pretty well regardless of the Practice referenced.

But for Information Architecture, there’s talk that our Context of Need is “wherever some information needs to be organized” and I think that’s dangerous, if we want to have a Discipline, and earn consistent legitimacy and authority in the wider world.

My Contention on the IA Context of Need

Information Architecture happened because of something extraordinary — the Web. I know lots of people say “oh we’ve been doing IA for a long time before the Web,” but my contention is NO. We have not.

What people were doing before the Web was a set of Activities that were applied in other Contexts of Need, as represented by Disciplines and Practices that were already around: Library Science, Architecture, Interior Design, Anthropology, HCI, Graphic Design, Brand Management, Copywriting, etc.

But then the Web happened. Hyperlinks became no longer a specialized concept in computer labs and musty research networks. They became available to everyone who had access to the Web, and access exploded.* Soon after, anybody on the Web was able to not only find and read things there, they were able to create things there themselves. (see Sidebar below on the importance of write-access)

The Web is the ultimate “shared information environment” — and I don’t mean a shared environment *of* information. I mean a shared environment *made of* information — the bricks and mortar are semantics and relevance. This is a key distinction.

Why weren’t people getting together for the stuff we now call IA before the Web? Yeah there were LIS people and the rest, but they already had organizations and practices and context of need of their own.

Something about the Web created a Context of Need that was new. Designers, scientists, writers … bunches of them realized there was something *else* going on that their previous activities and contexts hadn’t quite prepared them for. They realized they would have to adapt their expertise to meet this new context. Probably most people who now call themselves IAs (or their work IA-related work) had this epiphany at some point — they started out doing other things, but felt a need to adapt and evolve their work to meet a new context. That’s why they sought each other out and came up with mailing lists and discussion boards to begin with.

It just so happens that the book that appropriated the term Information Architecture for this new Practice (to deal with the new Context of Need) was written by LIS folks. And so, of course, it is written from that perspective. If the first major book to attend to the new Context of Need had been written by programmers or graphic designers, it would’ve been heavily slanted toward *their* tools and activities.

Over time, though, we’ve realized that, partly because the Web is so all-encompassing and mashes up so many parts of human experience, many other Disciplines and Practices have elements that can be appropriated and adapted for the Web Context of Need as well as LIS.

In fact, we need all those Disciplines and Practices to keep right on being experts in what they do, because their innovations are often helpful for us.

But guess what? It turns out they need the IA Practice to do the same thing.

At some point I want to write further about why I think it’s important that we not confuse Information Architecture with non-digital environment design, but I won’t belabor it right now.

I just want to make this clear: we need to focus our description of what we do, and the value we bring. We need to come to some shared understanding on what Context of Need we *primarily* address. Without that focus, we allow Information Architecture to continue to be viewed by many people as just a fancy name for stuff that other Disciplines and Practices already do. We don’t do ourselves any favors by trying to define ourselves with contexts of need that other practices and disciplines already cover quite nicely on their own (even if they don’t always do it well). Just because another Context of Need can be helped by some excellent taxonomy and card sorting work, it doesn’t necessarily mean IA is the best Practice for the job.

I hope this model, and my ruminations, can maybe help build toward a little more clarity. Or at least a language we can use to move things along a little more.

* Sidebar: The importance of write-access: All Web 2.0 really is, in my opinion, is the rise of write-access. For the first chunk of time, even though the Web was growing fast, it was mainly useful as a place for information retrieval because most people couldn’t *write* to it, only read from it. And even where they could write to it, most people hadn’t had it around long enough to mentally switch from a broadcast mindset to a peer-to-peer mindset… we were all trained to be broadcast to, or to find and read and use things other people made.

While information retrieval is still exceedingly important, the infrastructure has blown the doors off of write-access, turning the Web into the Peer to Peer network that it was invented to be. The scientists who wanted to use it to begin with all had write access. It just took a number of years for the infrastructure to mature enough that non-experts could write to it as well, and a few years more for it to sink in that “holy crap I can make stuff here too!”

Web 2.0 is just a rediscovery of what the Web was about to begin with: social, peer to peer communication. Whether it’s about science or comic books or sex or buying stuff — it’s all conversation. It’s all social interaction. Information retrieval and search are just tools we use as part of the whole.

Tags:

  • http://livlab.com Livia Labate

    Hurray. Between this and David Fiorito’s succint description of IA, I’ll stop debating it… for now :)

  • http://thinkingandmaking.com Austin Govella

    Is Mr. Fiorito’s description online? And I like the layer model a lot. Very clear division we can use for marching orders.

  • Nancy McCrave

    This is great! You took the more frustrated/pessimistic view that has been rolling around in my head and turned it into a positive. There are other reasons for defining IA, such as billable rates, scope definition, sales, marketing, job descriptions, etc. It’s a little scary to salespeople and to prospective clients/employees to show UX with 30 or so tasks/deliverables underneath. They can better understand/sell UX when it is represented in more manageable, bite-sized chunks, like specializations, like IA. Anyhow, very well done. This is a great starting point that I hope will generate a lot more conversation. I for one am not in any way tired of discussions that define the damn undefined thing.

  • http://www.eddiejames.com Eddie James

    This may be taking things down to too low a level, but it’s interesting (to me anyway!) that a big part of the confusion about what IA is comes from the fact that each of us as practicioners defines ourselves differently. We may have IA as a title, but we all come at this field from different backgrounds and are dragging our past lives around with us.

    Some think of themselves as “experience designers” so they naturally want to extend their skills to areas outside the digital world. Why can’t someone who wants to design experiences design the information flow of a supermarket or library?

    Others might define themselves as “interaction designers” or “librarians” or “programmers” or “product managers”. Each of these definitions changes the way we practice IA.

    Part of me feels IA is similar to acting. Julia Roberts and Jennifer Tilly are both actors, but I wouldn’t think they’d be competing for the same role. They bring different things to the table and are good at different things.

    It’s the same for doctors. They specialize in a particular field or are general practicioners.

    Maybe IA is really a specialization, but the difference between IA and other specialties is that most people with the title of Information Architect actually don’t do IA all day. I think they do do a mixture of a lot of things depending on the needs of the project. One project, I might be more user researcher and the next I might be more interaction design.

    I also wanted to say that I do think IAs can point to what they’ve done. It’s very tangible.

    I know that when I am on a project, I find it very easy to point out my value. Actually, I don’t usually have to; others on the team are quick to point it out. I ask questions, shape the way the business thinks, give a fresh analysis of the user data. And most important, I draw pictures of ideas. A visual is a very powerful tool to get concepts across. Your own chart above proves this point.

    I totally see the need to define IA and I think you have really hit on something, I just think there is room in this field to several flavors.

    Thanks for putting so much thought into this. You have definitely inspired me to think about this more and to write up my thoughts and ideas. Heck, I now want to make some kind of chart!

    eddie

    PS. Your description of Web 2.0 is right on. I totally agree. I could never put into words,so thanks for doing it so clearly.

  • http://www.inkblurt.com/ AndrewH

    Response to Eddie:

    Thanks for reading it!

    Just to clarify, I’m not saying that we have to all agree to the boundaries of IA in order to be professionals, or to be a community of practice like we are now. Those entities don’t require *definition* … only *description*. And the description can include all kinds of variations, exceptions, and fluidity.

    What I am saying is that, if it’s necessary to have a *discipline* then we have to at least agree to a more unified description of our practice. That’s necessary in order to have a defined *discipline* in IA that has a specific *definition* — with the ensuing ability to create standards and professional licenses and standardized curricula and the like.

    This blog post is neutral on whether or not we really *need* a discipline. But I personally think it would be powerful and useful for the profession to have the discipline defined and enabled. We can’t do that, though, until we decide on a context of need…

    I have no problem with IAs going out and designing supermarkets. If Frank Gehry can make jewelry and Michael Graves can make toasters, why not, right?

    But anything you do in a supermarket beyond designing and integrating the *DIGITAL* information environments there into the physical space is expertise that’s covered by another *discipline*. So… IAs can do that all they want, but it won’t work terribly well as a core context for our expertise.

    Also, yeah I can point to a lot of things that are in the background of a project that are “IA” artifacts and value — but in the finished product, it’s harder for us to point to what we brought to the table. Not impossible … it just takes more education and perspective. It’s something for us to work on as a community.

    Thanks again for the thoughtful feedback!

  • Richard Dalton

    Andrew – by god you’ve done it!

  • Priyanka

    Andrew, I love your approach to look at IA from a layered perspective and to keep the discipline aspect separate from the practice. It does a great job at addressing the layers of complexity in the field. Thanks !

  • Patrick Lowery

    Andrew, I finally get the point you were making about interior design vs. IA – it’s a skill that a lot of us might have, and even practice, but not central to the discipline. And I think Eddie has hit on the reason behind the disagreement. Whenever someone asks me whether a particular task is the IA’s role, or the information designer’s, or the writer’s, part of me thinks “it depends on what IA and designer and writer we are talking about.” Individual skill sets vary so much, and the most successful teams let the lines move a little bit depending on the players, in my experience.

  • Brenda

    It’s interesting that you chose housebuilders as an analogy… ever since the Baltimore Summit (2000?) when I heard Peter Morville relate the stonecutter analogy to the evolution of the IA profession, I’ve used it to describe the “state of things” to newcomers to the field, to describe when/where they might fit in. You know the one… a person comes upon 3 stonecutters, asks them one by one what they’re doing. The first says “I’m working to feed my family.” The second says “I’m trying to be the best stonecutter I can possibly be”. The third says “Well, sir… I’m building a cathedral.” If you think of the stonecutters as the things each one of us does as an IA–cathedral-building/discipline, master stonecutting/practice and clock-punchers/activities–I think there are some parallels to your model. I agree that just about any profession would fit into the model. But I’m glad to see IA specifically talked about in all 3 facets at once; we tend to get ourselves wedged into one layer and then waste an awful lot of time arguing our way out. Thanks for sharing your thinking.

  • http://www.jarango.com Jorge Arango

    Andrew, thanks for this article — it is a very useful perspective. I find it interesting how pervasive construction (brick and mortar) metaphors are in this field.

    With regards to this:

    “Unlike our friendly housebuilders, we can’t point at a shelter and say ‘we make that!’”

    Could this be because we are looking at the wrong group for an analogy? What we do is closer to architecture (brick and mortar) than housebuilding. Architects can’t point to a building and honestly say “we make that!”, but they _can_ point at the building and say “this exists because I harmonized a variety of disparate elements and created the plans that enabled the builder to make it!” (or something like that. Whew, what a mouthful!)

    In any case, I’ve used this analogy in the past to help explain what I do: “what architects do for buildings, I do for websites.” Most folks seem to understand this (as far as they understand what architects do.)

  • http://www.inkblurt.com/ AndrewH

    Reponse to Jorge:

    I regret using “housebuilders” as the analogy to some degree … I didn’t want to draw that comparison literally. I was trying to just describe the difference between a activity/tool (saw) and the practice (housebuilding) — I agree about real architecture as an analog. But honestly I don’t even see it as just an analogy. I think I quite literally create architectures for information environments (i.e. made of digital information).

    But even architects can point at a building, because the actual physical structure is made of walls. Pointing to the harmonization of disparate elements is harder to do when you don’t have a big honkin’ structure for people to notice — on the Web, the structure is invisible, between interfaces. Architects can skin their buildings in cool aluminum and stuff, but the only physical manifestation of our work is the interface, which Interaction/Visual Design is primarily responsible for.

    I’m not saying it’s impossible, just harder for us.

  • http://crosswiredmind.com David Fiorito

    BINGO!

    Man. You said it. You have a way of saying what I am thinking in a way that makes more sense than I could ever make.

    I think IAI Board should read this. Our community needs to be thinking about this – where we are and where we are going. You have given us a cognitive map that we can use to frame the discussion.

    awesome.

  • Pingback: .cross.wired.mind.

  • Marsh

    A few random thoughts

    I think the housebuilding anaolgy is apt – in a previous life I was an Interior Architect I (and others) described the practice as like Architecture only backwards. I would suggest the IA is much like web design only backwards…

    The comparison is apt also in that both are concerned with the design of environments and the attempt to structure them in a way that allows users to make sense of them. That IA need not be concerned with physics is in someways a blessing but of course it must adapt to it’s own set of constraints – e.g. usability(maybe).

    The differnce is in the dimensions – architecture in many respects and most cases is designed to be understtod in a single (or only a few ways). Web must be always understood in many ways as there is rarely a right answer to the complexity of web navigation.

  • Pingback: inkblurt » Blog Archive » The trouble with defining Information Architecture