Site Map Do's and Don'ts

It may come as a shock to hear this, but, unless your client is a developer or a content strategist, site maps are rarely valuable documents to show them. Why then, is the site map continually socialized to the wrong stakeholders, and incorrectly positioned as a dependency for other Design deliverables (Which we know will result in the site map becoming a road block for the rest of the Design process)?

Site maps confuse and distract certain stakeholders, because:

• Site maps are abstract, system-level documents - They document a system, but are not visually representative of that system at an interface level. Consequently, they take a certain level of extrapolation to understand how the hierarchy works, at a page, or screen, level.
• Site maps can appear dense or complex - Site maps take time to study and understand. You'll likely have about an hour, max, to present your site architecture to your client. How on Earth are you going to convey that level of complexity and detail, in that amount of time, especially to a "C-Level" executive? When designing a site map, think about simplifying the diagram, or presenting multiple views of the map, "peeling away the layers of the onion," to gradually expose more detail.
• Site map "approval" is typically considered a dependency for the start of the Design process - Yeah. It's weird to think that everyone on the team expects the Information Architect or User Experience Designer to completely nail the entire taxonomy and flow of an application, without even having sketched a screen or two. Word of advice...don't hold up Design, while awaiting site map approvals.
• Site maps are NOT good for presentation of a UX vision - There are more effective visualizations, infographics, and high-level diagrams that can be utilized to convey the User Experience Vision, or Strategy, for an application, to a marketing executive. The interconnection of pages or screens isn't a visualization of a strategy. It is a visualization of a content hierarchy.

What are site maps good for, then, if they aren't great tools to convey the high-level vision for an application?

• Site maps are good for development and implementation - Site maps are invaluable documents to illustrate to developers, how to construct the hierarchy of pages or screens in the application. It is a document that is generally delivered to a client or team of developers, prior to the screen level user interface designs. That being said, I strongly recommend that site maps are not considered "FINAL," until the very end of the Design process. There. I said it!
• Site maps are good for content development and categorization - Because site maps represent the "outline" of the content, they need to convey, in some cases, the flow of the narrative to the end-user. This is especially true when designing the information architecture of a marketing web site or application. Content strategists and developers will want to map their copy and content to the site map sections and sub-sections.
• Site maps are good for SEO planning - The underlying framework of a web site is extremely important, when planning for the search engine optimization of a web site. It is critical to understand the likely searches that consumers will perform to access the client's web site, and create an information architecture that will, at a primary level, satisfy likely searches. Thus, the site map becomes a communications tool amongst four parties:
• Information Architects/User Experience Designers
• Copywriters
• SEO planners
• Developers

Of course, old habits die hard. It will take a long time before agencies realize that they shouldn't, out of habit, shove the "site map" deliverable at the beginning of a project plan, and require the client "sign-off" on the document before the Design process begins. But, please don't force the client's CEO, or CMO, to sit through that presentation!

Jonathan Lupo - http://www.twitter.com/userexperience