what is information architecture

When I was first introduced to the field of user experience it was the summer of 2005. After leaving my job as a Java Programmer in Hartford, CT I moved to San Antonio, TX where I randomly fell into a UX job (talk about lucky). It’s an understatement to say that I had no idea what the hell I was doing, and I scraped along for awhile trying to figure it all out. Back in those days, my role was not UX Designer or Interaction Designer, in fact, the term UX didn’t even exist in my world! Instead, those of us that weren’t visual designers were called Information Architects, and that was exactly what we did. It was our job to architect, organize and make sense of the information within a website or application. After we mapped that out (either in an IA doc or some sort of concept mapping), we worked with a visual designer to put our mapping into an interface.

Unlike a lot of what we see today, the first thing I did on the job was NOT learn how to wireframe. In fact I didn’t create my first wireframe until I moved back east to NYC almost three years later. Instead, the first thing I was instructed to do was visit Jesse James Garrett’s site. I was tasked with understanding what the Visual Vocabulary for describing information architecture and interaction design was from a conceptual standpoint, and was then expected to map out IAs for my projects. There are several reasons why this was my first step. Reason one was that we IAs and VDs simply needed to know how information was related and prioritized within a website or application before we could design the interface for that system. How else can you design a proper interface solution unless you understand which information types need to be included in that solution, and which are most important to the solution? Without knowing this information, we would have been guessing at the interface. Reason two was that we didn’t want to show an interface to our non-design partners and stakeholders as our first deliverable because what we really needed from them was not feedback on the visual, but feedback on the content and context that related to the system. It’s seven years later, and, sadly, it seems that the time I’m speaking of has come and gone. And, because of that we are facing a huge problem in the world of UX.

The problem UX is facing is, simply, we are devolving. The definition of de-evolution is to degenerate through a gradual change or evolution, and it seems to me that by removing the information architecture step from our day to day process we might be on that path. To be fair, I’m not saying how that IA phase should be structured in detail (that is for another post), but I am saying that this type of thinking needs to be done and signed off on by certain team partners before we can move into interface design (including wireframes).

We see several problems that come out of skipping the IA phase. First, the team (UXers, Visual Designers, Project team members, other stakeholders) won’t all be in agreement on the prioritization and context of the information to be designed for which will cause disagreement in later phases. Second, by showing wireframes without agreeing on IA, we are focusing our stakeholders and other partners on the interface and not on the real thing we are designing for… content and context. Third, we are, in essence, beginning to lie to ourselves. We are lying to ourselves by telling each other than UX is not just about form, but it is about function as well. Because if it was about function, we’d spend time on the information (the IA phase) before we went right into talking about the form that the information should take (the wireframe phase).

To make matters worse, we, as an industry, have been trying to validate the discomfort that many of us feel subconsciously with skipping the IA step, by turning to “sketching” as the end all be all answer. Of course, sketching is important, but it all matters what we are sketching and when. What I’m talking about is that we UXers think that since sketching doesn’t involve putting our wireframes into an electronic format, than it doesn’t really count as skipping straight to wireframing. But guess what, even sketching the interface without first sketching the structure of the information means you are skipping the one step that will make your designs truly successful. That step is where you think about the content, context and users, and force your stakeholders to do the same, WITHOUT thinking about the interface (also known as the IA step).

So where do we go from here? How do we stop this process of devolution and backwards movement? Well, we bring back IA! Ok, ok, I’m not saying that we should all learn Jesse James Garrett’s Visual Vocab (though it wouldn’t hurt) or that we need to institute a structured process that we follow the exact same way every time. But, what I am arguing we need to do is slow down, put down our sketching pens, and our omnigraffle and just think. Think about, draw out and get buy in on your content, your context, and your users. And do so without a wireframe or a sketch of a wireframe. Pick up the Polar Bear book, and ignore the wireframe chapter and learn IA.

By bringing the IA phase back and by concentrating first on the information, several things will happen. First, your sketching and interface design becomes much, much better because you have prioritization and buy off on the content, context, and users you are designing for. This means that your wireframe/prototyping phase becomes a lot more about the interface and not what content should go in the interface and why. Second, you are showing your stakeholders that UX design truly isn’t just form, but really is also about function. We are moving away from the interface, which is how we started, and towards a real solution of which the interface is only a part. Third, we stop lying to ourselves, and we stop saying that the best UX solutions aren’t just the coolest or the best aesthetically, but they are those that take content, context and users into consideration while creating an aesthetically appropriate interface. Most importantly we stop UX’s slide down the evolution scale back towards the time of print design and outputs, and instead continue our climb up the mountain towards being the user experience experts.