UX 101: The Site Map
TJ Ward, Former Viget
The beginning of a project is a magical time. Your vision is clear, untainted by the realites of implementation, and the possibilities of what your site can be are spread out before you like an indian buffet. The task may look a little daunting, but there are a number of sexy things you can start working on. I know you want to start talking about development frameworks, interaction design, and logo design, but there's something you need to get right, right now, if you want your site to come together on time, on budget, and on point: your information architecture. You need to define what information your site is going to share and how it's going to be organized.
I know it sounds like I'm stating the obvious, but I also know how easy it is to get ahead yourself and skip right over such mundane questions as "what goes in the primary navigation?" You could skip it and start writing code or picking our colors, but building a site before you know where everything is going to live is a lot like building a house before you know where you're going to put the kitchen.
In the case of a house, the builder has a floor plan and blue prints to guide them, so what about a website? For that high level, what-lives-where plan for sites and apps information architects turn to an often misunderstood staple, the Site Map.
What's a Sitemap?
A site map is like a floor plan for your site. Site maps give you a visual representation of the site's organization and how different sections are linked together.
Sections can contain other sections or content nodes, which is an atomic unit of content. Oftentimes on a web site, a content node ends up being it's own page, but IAs prefer to talk about nodes at this stage because a single node can be represented in a number of ways (a page, a pop-up, a light-box, a section of a page) and/or in a number of places (a blog post, for example, gets it's own page and shows up on the home page when it's new-ish).
In short, a site map is a 30,000 foot view of the site (and all it's content) that puts the project team on the same page so everyone can get started doing their own high-level planning.
Why mess with sitemaps?
Different constituencies on a project will get different things from a sitemap. Stakeholders can use site maps to confirm that the direction the site is heading is the right one and that their goals are represented in the organization. Developers can use a site map to validate assumptions about scope and complexity and as an early view of feature requirements. Visual designers can use a site map to get an idea of how much variation may be required and whether the design will need to be modular and extensible. Finally, UX designers will reference the site map when the design wireframes (see UX 101: The Wireframe). The hierarchical information in a site map tells a UX designer what sections will need to be in primary and secondary navigation and where inter-section paths will need to be added to make appropriate sections of the site accessable.
What to look for
While your role and responsibilities on the a project will influence what you can glean from a site map, there are things that everyone on the team should look for.
Regardless of your role on the project IAs and UX designers always appreciate feedback on the organization of a site. When you look at a site map remember that you're looking at the floor plan of the site. This document should show every section of the site, so make sure that all of the sections that you think are important are accounted for.
Look at the number of sections. Does each one need to be there? Are there any sections that try to cover too much? Both too many and too few sections make it difficult to find things. Include too many sections and your users may be instantly overwhelmed and not know how to start; too few, and your sections will lack the descriptive power to give users confidence that they'll find what they're looking for. There isn't a "correct" number of sections for all sites, rather, it depends on the scope of the site and the content.
Within each section make sure that all of the sub-sections and sub-pages are present. People typically use site maps to represent each page on a site, so if something isn't present it doesn't necessarily that the designer didn't consider it, they may have, rather, considered it a subject for a page that is represented. If it's important enough that you think it should be its own page, though, make sure you bring it up.
Another important thing to look for in a site map is a clear expression of the primary navigation. This will typically take the form of the first level of hierarchy under the homepage. Sometimes, the designer will call out sections in the primary navigation to make it obvious. Consider whether the sections that make up the primary navigation are actually the most important and commonly accessed.
Also consider whether the section names are meaningful. Do they describe the section clearly? nbsp;Will the people you expect to use the site know what they mean? There's still plenty of time to get language just right, but every layer of design and development that follows is going to make decisions based on what you find in the site map and the sooner you get it right the fewer changes need to made down the road.
Let's review what we've learned:
• A site map is a visual representation of a site's organinzation and how content nodes will relate to one another. Nodes often end up being their own pages, but not always.
• Different people can use the information in a site map in different ways.
• When you're reviewing a site map make sure all of the important sections, sub-sections and pages are represented.
Site maps are an important tool for organizing your site content and documenting your site's direction. Once you've got a site map in hand, everyone on the project team can use it as reference to stay synched up and headed down the right road.