How to create a sitemap

I used to think sitemaps were a waste of time. I thought it was a deliverable only UX people could love, with all those abstractions and boxes and arrow. So, I focused my attention on showing clients navigation schemes, wireframes, anything that got us closer to talking about the actual interface.

I was wrong! Creating a sitemap should get you to think about what content you’ll have on the site and why it’s there in the first place. Site organization and labels—my typical focus with a sitemap—are still important, but should be secondary to figuring out what’s on the site and why. The key for me was to separate the thinking from the ultimate deliverable.

[The thinking - table view]
[The deliverable - client facing]

My sitemaps always start with a three column table: Page Name, Content Source, and Notes. Also known as: what is it, where’s it coming from, what’s it for? Each row in the table represents a single page in the sitemap.

Page Name

This column contains a nested view of the pages that I propose we have on the new site. This column contains two important pieces of information: my recommended name for each page, and the relationship of each page to other pages.

Content Source

This is the hard part. Where is this content coming from? Each cell in this column should have one or more sources—URLs to the current site, references to print collateral, or other offline content. That sort of thing. Or it should say “new,” to indicate that this is a page for which no content in any form exists. Rarely is there a one-to-one migration from an old site to a new one, so a thorough content audit is needed to spark discussion about what content to keep and what content to jettison.

Notes

Do not leave this blank. Try to summarize in one sentence what the purpose of the page is and what content you expect to see. You want the client to focus on the content, not necessarily about how it’s organized (that’s your job, after all). This field is also a good place for notes about content maintenance, planned functionality, and

Here’s the secret: this method forces you to consider the content up front. Sounds like a no-brainer, but believe me, lots of sites get designed without much thought put into what the content is going to be. Too often, UX people get caught up in creating containers and relationships for content without actually thinking about what fills those containers. Resist the temptation to leave any cell in this table blank. Blank cells are where assumptions live.

Now that you have this, you should have a pretty good vision of what content will be on the site and how it will be organized. This vision should make it so that you can talk to clients much more clearly about what content users need as opposed to how users navigate pages. It sounds like a small semantic quibble, but it’s made a huge difference in my approach.

Comments are closed.