When I talk about Information Architecture, I don’t want to talk about deliverables. I want to talk about getting people on the same page about what is going to be built or designed. The gist of my job is getting “consensus” (and I don’t mean designing functionality by committee; I mean ensuring that that everyone understands what is going to be built before the development and design happens). Yes, there will always be changes, and yes, agile development can be a great thing. But without some sort of initial blueprint to guide you, the project will flounder around in a visual design and feature development tennis match—on a court without lines or a net. In short, you need a solid plan or you’ll end up with a mess.

So, you need a process for getting people on the same page. In a perfect world a napkin sketch, phone call, and thirty minutes on a write board would be sufficient to give everyone on your project a clear understanding of what’s going to be built, and you’d be ready to move on. But this is a fairy tale. Clearly documenting everything, getting all your stakeholders in the room at once, making time for client feedback, and discussing your work with clients so they see how the site is developing take a lot of time. A whole lot.

Unlike visual design and development, information architecture has a whole slew of deliverables to choose from. Every project has different requirements, so you’ll need a slightly different set of IA deliverables for each one. Whether you’re working with a web application or a more traditional content driven website, for instance, makes a huge difference. And of course, you also have to consider budget and the type of client you’re working with. The problem is that it’s not always clear which deliverables are going to best facilitate getting everyone on the same page. As well, it’s easy to forget that deliverables themselves don’t matter much — it’s understanding that you’re looking for.

I’m going to be writing a series of posts about the deliverables I use and explain why I use them. I’ll begin with one of the most common deliverables, and one I almost always start projects with: the Site/Navigation Structure document.

Traditional content-driven sites and Site/Navigation structures

If you’re not familiar with the Site/Navigation structure document, here’s the gist: It’s basically a set of boxes that outline the general categories, sections, or main navigational items for a site (It is traditionally called a site map). The Site/Navigation structure document is not particularly sexy, but it’s a great way to get people to think in terms of general site navigation and site priorities. It also prompts them to consider the content they have, want and need. I usually try to included the secondary levels of navigation as well (boxes underneath the main navigational boxes) to help provide even more context. I avoid getting into too much cross linking of content, as that tends to get a little more detailed than I want early on in the discussion. In the early stages, I like to focus on main navigational elements and try not to get too bogged down with the details.

One, possibly two rounds of revisions are usually all that’s needed with this deliverable. The beauty of this document is that it’s usually fairly easy to create (although a lot of time is spent looking through content, site, or any additional documents your client has provided) and it’s quick to change. I spend a good amount of time writing up my justification for the site structure with this as well. It’s not a very visual document, so I find it really helps to outline out what I’m thinking in a Basecamp post when I send it over. Depending on the client, I then spend some time either on the phone or reading through their feedback. Then I move on. It’s important not to get too bogged down because remember, it’s a process and these are just being used to document design decisions.

Web applications and Site/Navigation structures

Web applications are a bit trickier when it comes to producing a more page-driven site/navigation structure. I usually try to stick with a similar layout, with larger boxes representing the main navigational elements on the page and smaller boxes underneath representing sub pages. Often, I’ll add in a bit more detail to help show some of the process or interaction happening on some of the interior pages. Without more detail up front here, I find it’s just too general for all that needs to be explained. It’s a bit risky to spend so much time creating and revising initial deliverable like this, but I’ve found that without it, the feedback can be a bit lacking and general.

Overall, the Site/Navigation Structure documents (when done correctly) are a great way to get the conversation going, and of putting a quick but nice-looking deliverable in front of the client. This deliverable also helps make sure that everyone is, for the most part, on the same page before you move on to more specific IA deliverables.

Next up: Page Descriptions Diagrams.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.