When we’re preparing a site structure for tree testing, one of the most important things to decide is which headings to include and which to exclude.

In general, we recommend to:

• Include global navigation items, unless they’re very minor

• Exclude links or shortcuts that are not in the global navigation

• Exclude “escape” headings like Search, Contact Us, Help, etc.

Including global navigation

In What is tree testing? in Chapter 2, we saw that the purpose of tree testing is to evaluate the top-down structure of a site – that is, whether users can find what they’re looking for by browsing the site using its top-down navigation.

In most sites, this top-down tree structure is represented by the global navigation. Most often this is a row of tabs or headings across the top (or down the left side) of each site page:

Open

Using the example above, our tree would clearly include the main tabs (Making a Claim, Preventing Injuries, etc.) and the subtopics under each of them.

But what about the other global navigation links – the ones that are in the header, but are not major tabs? In the example above, should we include News and Publications in our tree?

In general, the answer is yes – we should include most global navigation items in our tree, because they are top-down navigation links available on every page of the site.

Notice that we said “most”, not “all”. There are often other items that are so minor that they would just add clutter to a tree test. In the example above, we might choose to exclude the social-media buttons, unless we intended to write tasks that involved them.

What about footer links?

In most sites, it isn’t just the header that provides global navigation. The footer usually does a little (or a lot) of this as well.

Sometimes the footer just repeats the major navigation from the header, or even expands it to show the second level as well (the popular “mega footer” pattern). In this case, the answer is easy – omit the footer links, because we already have them in our tree (from the header).

What about additional links in the footer? For example, here’s the footer from the example site above:

Open

Should we include Glossary, Privacy, and other links like them?

The answer here is the same as for minor links in the header: we should include them if we think they’ll affect the test, but we can exclude them if we’re sure they would just be clutter.

In the example above:

• We would probably include Glossary, because we could imagine some participants going there for a given task.

• We would probably exclude Privacy, because it’s rarely visited for everyday tasks. For the purposes of our study, it's just clutter.

Excluding non-global links

When we’re deciding which headings to include, we must be careful to distinguish between:

• global-navigation links

• "featured" links on a page

As discussed above, we are looking for links that in the global navigation scheme (usually a menu system), to provide users with a way to find content by browsing.

Here’s an example from a government education site:

Should we include Find term dates and Find a school in the top level of our tree? After all, they’re going to be used by a lot of home-page visitors to navigate to important content.

The answer in this case is a clear “no”. While these links are prominent on the home page, they do not appear on most pages of the site (presumably), so they’re not part of the global navigation. Remember that we’re not just testing navigation starting from the home page; we’re testing navigation from anywhere in the site, especially because of how often visitors arrive at subpages via deep links or search engines. These links should only appear in our tree if they have a place in the site's menu hierarchy.

This also reminds us that tree testing is not enough on its own. While it will test top-down browsing, it will not test the effectiveness of surfacing important links on a given page. In the example above, featuring Find term dates will definitely affect how users navigate from the home page itself, but that needs to be user-tested with a tool that can show actual page layouts, visual design, and so on.

Excluding “Overview” headings

In many content sites, each major section has an introduction that describes what the section is about, and which topics will be covered. Often this is labeled “Introduction”, “Overview”, or something similar. Here’s an example from a power company:

In general, we exclude the Overview topic from our tree when we test it. Why? Because while it often mentions content that is covered in more detail later in the section (and could therefore be considered a “correct” answer for a task that asked about that content), it’s not really where the “real” answer is. And because an overview may mention a lot of different topics, we don’t really find out if the user was looking for the right thing.

It's also important to watch for the opposite problem – content hidden under a main heading because it doesn’t have a subheading of its own. For more on this, see Spotting missing content later in this chapter.

Excluding Search and Site Map

We exclude Search because we’re testing how users browse.

If we include Search, many participants will encounter a task and say to themselves, “Hmm, I’d probably just search for that”, click Search in our tree, and the task would end. While that’s a useful result in a normal usability test (observing that the user chose to search instead of browsing), it doesn’t tell us much about how effective browsing is.

By excluding Search, we’re effectively saying to them, “Yes, you might search on the real site, but if you had to browse, where would you go?”. This way, each participant gives us useful results on every task.

As for Site Map links, we exclude them because they’re redundant; the textual tree we’re presenting is a site map itself.

Excluding Contact Us, Help, etc.

The reasoning we use for excluding Search also applies (usually) to Contact Us, Help, and similar headings. These are often used as “escape” choices, where the participant scans the list of headings, doesn’t find anything promising, and says to themselves, “Ah, I’d probably just call them and ask.”

While that’s a useful finding (none of the other headings seemed to match), we’ve found that providing a Contact Us topic or Help topic (especially at the top level) makes it a bit too easy to bail out on a task. We might learn a little, but overall it’s better to make them either pick a “real” heading or skip the task entirely.

The only time we want to include Contact Us or Help is if we’re actually testing subtrees under those headings. For example, we may want to know if users can actually find items in our Help system, so we include a subtree of topics under Help. The trade-off here is that we will almost certainly get less feedback from other tasks when some participants use the Help topic to bail out of browsing the main tree.

Dealing with faceted browsing

Tree testing is well suited to static content sites, where the grouping of topics and their subtopics doesn’t change on the fly.

Occasionally, though, we may need to model a tree that includes faceted browsing/search, where the subgroups change dynamically.

Here’s an example from eToys.com. In their Outlet section, we can browse topics such as Action Figures…

…then browse by lots of subtopics:

The problem here is that we’ve wandered into a faceted search, where choosing a subtopic like Gender > Girls filters the search results, but still offers all the other subtopics to continue filtering by:

If we wanted to model this in a tree test, we would need to offer every subtopic under every other subtopic, and then every remaining subtopic under that subtopic, and so on all the way done (until we ran out of topics). Trying to create a static tree of subtopics from a dynamic set of facets is a lot of work, and probably not worth it.

We have two alternatives here:

• If this was just part of a larger site, we might just model the faceted section one or two levels deep, to see if our facets betray any glaring problems.

• If we really want to find out how well the faceted browse/search itself works, we’ll need to develop a working faceted search UI and do usability testing on it. Tree testing is just not the right method for this.

Dealing with complex navigation

Some sites are hard to model in a tree test because they have inconsistent global navigation – that is, their top-down browsing structure is hard to determine based on the headings they present.

WebMD, the popular healthcare site, is a good example of this. At first glance, it presents what looks like a fairly standard global navigation scheme. Here is the Living Healthy section, with a strip of secondary navigation (Health Beauty, Food & Recipes, and so on):

If, however, we use the mega menu that appears when we hover over the Living Healthy tab, we get a different set of topics and subtopics:

Clicking through the WebMD site further, we actually find 3 or 4 different ways that they organize topics, some of them overlapping.

Because tree testing insists on a consistently “top-down” browsing structure, it would hard to run a fair tree test on sites like this. A conventional usability test of the actual site would be a much better choice.

Next: Spotting missing content