Information architecture deliverable: Site maps (with pictures)

It’s good to know what information architecture deliverables you can expect on a project. Whether you’re working on a website, intranet, or another content management system implementation or redesign, there’s a few usual suspects for information architecture deliverables:

Site maps
Card sorting
Task testing
Content model or metadata model
Page flows
Wireframes

This article looks at site maps.

Site maps

Some people use the terms “site maps” and “information architecture” interchangeably to describe the page structure for a site. You can make a site map in Excel, Slickplan, or any other tool.

What does a site map show?

The key things to show in a site map is the hierarchy of pages: the home page, the landing pages, the child pages, and the number of levels in the site. It shows how all the static pages on a website or intranet are related.

Some sites are small and can list all the pages on the site. Other sites might be large and can only detail down to level four or five.

How do you make a site map?

I produce a site map based on a content audit, user research, business needs, persona needs, and content gaps. I put this all together into a two-dimensional representation of a website.

Why do you need a site map?

A site map lets you agree to the page structure of a site before creating the pages on a website. It is much easier and cheaper to represent and revise a website structure in a spreadsheet than it is to create all the pages on a website then try to restructure the website.

How do you know if a site map is “right”?

A site map should represent all the content you want to have, including the content the business needs, the users need, that you want to carry over from the old site, and any new content. I would then review this with stakeholders, test it with TreeJack or some similar tool, and revise it.

This stakeholder review, Treejack testing, and revision could happen two or three times, depending on the complexity of the site, questions about the structure, and internal discussions and external testing.

Who should review a site map?

On my projects, I typically start with the core project team, or people who have been involved on the day-to-day website redesign work. These people generally have a good handle on the subject matter, although they may not be subject matter experts. After this review, I would open it to the larger stakeholder group or do task testing with the target users. It depends on how much feedback I need to get about the subject matter and the domain.

What do you do once the site map is done?

You can move on to content modeling, taxonomy development, and wireframe development.

At this point, how final is the site map?

Let’s review what’s gone into the site map. To create a site map, I have done:

User research
Stakeholder engagement
Content gap analysis
Persona creation
One or more reviews with the project team
One or more reviews with the stakeholders
One or more rounds of testing with users

At this point the structure should be pretty solid. It will most likely be revised as the redesign continues and as writers create the pages. The writer has final say on the titles for the pages. The exception to this rule is that if there was a term or section that was problematic and I tested it and validated that the structure worked for users, I would advise against changing this. I make note of this in the documentation.