The Purpose of Site Maps and Other Design Deliverables
Published: January 25, 2016
In this edition of Ask UXmatters, our expert panel discusses the purpose of site maps. Web site design has come a long way since designers slapped a Site Map link at the bottom of every Web page to help users who were perplexed by a Web site’s organization—or has it? Sometimes yes, sometimes no. Our experts cover exactly what constitutes a site map and how site maps differ from other UX design deliverables. They also consider the evolution of the term site map over the years, how site maps apply to increasingly responsive Web designs, and how agile development has impacted the use of site maps.
Every month in Ask UXmatters, our panel of UX experts answers our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: [email protected].
The following experts have contributed answers to this edition of Ask UXmatters:
- Steven Hoober—Mobile Interaction Designer and Owner at 4ourth Mobile; author of Designing Mobile Interfaces; UXmatters columnist
- Cory Lebson—Principal Consultant at Lebsontech; Author of UX Careers Handbook (forthcoming); Past President, User Experience Professionals’ Association (UXPA)
- Mike Murphy—Senior Design Director at GfK
- Rick Omanson—Vice President of UX at GfK
- Jim Ross—Senior UX Architect at Infragistics; UXmatters columnist
Q: What is a site map? What is its purpose? How does it work? I’m not sure why, but site maps seem to have become confused with navigation design. I’ve seen site maps trying communicate user flows, navigation design, template design, and all kinds of strange things. It would be great if we could get a sense of when we should be using site maps and when we should be using other tools like content inventories or wireframes.—From a UXmatters reader
“Ah, the dreaded site map,” groans Steven. “Dreaded because the term’s got at least two different meanings. The first refers to the Site Map link on the footer of a Web site that displays a list of all pages on the site. Of course, with complex applications, data-driven presentation, 1:1 landing pages, and so on, there is increasingly no solid definition of what all pages means for a site. Also, such a site map can become a crutch, allowing teams to wave off poor navigation or architectural design decisions with ‘users can just use the site map.’
“But I’m pretty sure your question is about the other use of the term site map, which refers to a design model. Most clients who demand a site map seem to conflate these two rather vague concepts—neither of which is a very good solution to anything. Others—and maybe you—sometimes use the term to mean a task flow or a mental model or any number of other things.
“Overuse of the term site map means that, too often, a site map is a view-centric inventory—and that's bad because we actually design for experiences and interactions. I start all my design documentation with descriptions of the goals, objectives, and constraints, then various task-flow models. While these detailed models get called site maps all the time, they’re really not. The key parts are not the boxes, but the arrows, diamonds, clouds, and other symbols indicating what the system actually does, not just what it looks like.
“A task-flow diagram is not a wireframe in my book, because it is about designing the flow of the entire system,” concludes Steven. “To me, wireframe-level design documentation is more about information design—that is, it’s the next level down from the placement of content and interactive items on a page or view. Here, you can again extend the task-flow diagram to help, drawing it to indicate what sorts of functions are on each page or view. You can use that holistic design model to create user interfaces and interaction widgets. If you develop reusable ones, you’re soon in the business of creating 30-page specifications documents and solving problems on whiteboards instead of drawing 300 comps or making complete, clickable mockups of an entire process. I find it much easier.”
How Site Maps Differ from Other UX Diagrams
“A site map is a diagram that shows the organization of a Web site’s or application’s content and functions,” answers Jim. “It’s a way to visualize the organization and labeling of content. It gives clients and project-team members an overview of the Web site and how all the content will fit together. Some designers seem to be confusing site maps with other types of UX diagrams. Site maps typically use boxes to represent pages or page states and arrows or lines to show connections. But UX professionals, developers, and others use boxes and arrows in many other types of diagrams. For example, flowcharts had been around for many years before anyone created the first site map.
“Use flow diagrams show how people interact with a Web site or application. Instead of showing the organization of content, they show a person’s path through the user interface and what they experience. These may appear similar to site maps, so it’s important for designers to clearly label and explain these diagrams.
“While site maps, use flow diagrams, and navigation diagrams may look similar, content inventories and wireframes look entirely different from site maps. A content inventory lists the details of all the pages, documents, and pieces of content on an existing Web site. Its usual purpose is to inventory all of a site’s existing content to determine what will need to go onto a new Web site. You should create a content inventory at the beginning of a Web site redesign process, before creating a site map to plan the organization of the new site’s content. Information architects often create content inventories in an Excel worksheet.
“While a site map provides an overview of a Web site’s or application’s organization, wireframes show the designs of individual pages. Wireframes are usually early, black-and-white line drawings of the content and features on a particular page or screen.”
The Evolution of the Term Site Map
“I’ve watched the word site map evolve over time,” replies Cory. “Ten years ago, a site map was a page Web designers stuck on a Web site so, when users became confused by poor or convoluted navigation choices, they could theoretically turn to this site map, see tons of links that mapped out the organization of the whole site, and find what they were looking for. In reality, users didn’t very often find or think to turn to the site map, so it didn’t manage to compensate for poor navigational options.
“These days, the most frequent use of the term site map seems to be for SEO (Search Engine Optimization) purposes. The site map provides a way for a Web site to convey information to search engines about the pages on a site and when those pages need to be re-indexed. This type of site map is not typically visible to users as they navigate a site.
“Design teams sometimes use the term site map to refer to a document that conveys a site’s structure—although they may also call this a site outline, a site hierarchy, or sometimes just refer to it as the site’s information architecture (IA). However, in reality, the site map is a child of the overall information architecture. Whatever a team chooses to call this document and however they prefer to illustrate it, conveying the hierarchy of a site is essential, as is understanding the expected user flows and methods available for navigation. Understanding what content will be on a site, as well as the structure and behavior of the site is also critical. Wireframes often convey this information. Often, each of these is a separate deliverable, but that’s not a hard-and-fast rule. If it makes sense for a particular project, aspects of these deliverables could overlap or be combined.
“While a site map that is intended for users is not often a stand-alone page anymore, the same principles often apply to navigation that comprises a mega menu or drop-down menus, which frequently display multiple levels of a site hierarchy. In other cases, a mega footer lays out the top levels of a site’s hierarchy. While neither of these methods provides the comprehensive site map of days past, I’ve seen more successful implementations of these hierarchical navigation techniques validated through usability testing than I ever saw from the original site maps.”
Site Maps and Design Flow
“The primary purpose of a site map is to show the hierarchical organization of the pages or screens on a Web site or in an application,” agree Mike and Rick. “Nodes in a tree or hierarchy represent all of the site’s pages, with top-level nodes corresponding to top-level categories or tasks and child nodes corresponding to detailed content or specific tasks. The organization is a strict hierarchy, in which each page has only one parent.
“The most direct use of a site map is to identify the locations of the pages on a site. When you make a page’s location visible—by highlighting the selected navigation item or providing a breadcrumb—it provides orientation to users and helps them understand a page’s context, explore related pages, and find pages again during subsequent sessions.
“Since site maps lay out all the pages on a site, it’s often necessary to add metadata to page nodes for secondary purposes. For example, you can assign a number to each page that you’ll also use on wireframes, so the site map becomes a page inventory. You can flag pages for which links appear in the top-level navigation to assess the global coverage of the site’s navigation system.
“Although site maps do not describe the layouts of different page types—for example, product-listing pages and product-details pages—you can use site maps to show how different page types are distributed throughout a site, by indicating the page type of each node. Similarly, even though the connections on a site map do not reflect navigation paths, you can highlight a sequence of nodes in a site map to indicate the path a user would take through the site to perform a task.
“Content inventories and wireframes document different steps in the design process rather than mapping a site’s organization. Typically, teams create content inventories before creating a site map because a content inventory documents what content already exists on a site, independent of its distribution across various pages. In contrast, teams often create wireframes, which specify the layouts of individual pages, after creating a site map because wireframes include global navigation, which usually reflects the organization of the site that the site map describes.
“Despite the diverse uses of site maps, team do not often create them. One reason is that, on a responsive site, the number of pages may change, depending on the size of a device’s screen. Another reason is that, in an agile development environment, there is rarely enough time to create a complete site map. Thus, the lack of a site map results from the speed at which the team is moving. But lacking a site map may also cause teams to miss gaps, where pages are left dangling and isolated, while if there had been a site map, the team could easily have identified missing connections.”