Designing the structure for a website is never a lockstep 1-2-3 process, and different designers will approach it in different ways.

It’s always good, however, to start with some knowledge. In The research phase in Chapter 3, we described how some basic user research (such as contextual inquiry, open card sorts, and tree-testing the existing site) can give us a head start.

If we’ve done the research, we are not starting with a blank slate:

1. We know our users.
   Our initial discussions with stakeholders defined who our target audiences are, and some basic research determined what they want and how they go about it.
   
   
2. We know our content.
   A content audit has determined which topics we’re keeping, updating, adding, and deleting.
   
   
3. We know what’s right and wrong with the existing structure.
   A benchmark tree test has shown us which parts of the existing site tree work well (and should be reused) and which parts perform poorly (and need to be changed).
   
   
4. We have new ideas to try out.
   An open card sort has given us ideas about how users mentally group our content and which terms they use.
   
   

We can now sketch out some new structures to test. Let’s take a look at the most common ways sites are organized, and some common tactics that can help us create our own trees.

When you start creating a site tree, you will usually play with various kinds of top-level groups, probably trying some of the variations described above.

A very common tactic is to combine some of these schemes as first- and second-level headings. For example, you may use audiences as your primary navigation, then activities within each of the audience sections:

• diagram of audience>activity tree

You may then decide to try replacing activities with, say, geography:

• diagram of audience>geography tree

Another common tactic is to flip the primary and secondary navigation, to see if it fits the content better.

For example, the audience/activity tree that we tried earlier…

• diagram of audience>activity tree

…could be flipped to become an activity>audience tree:

• diagram of activity>audience tree

We may do the flip, think about it, and decide that it won’t work for our purposes (perhaps the content doesn’t fit as well, or we’re sure that it will be confusing for users).

But, if it looks reasonable, and we’re not sure how well it will work with users, it’s probably worth testing both versions in side-by-side tree tests.

When we create site trees, a common question is “Should we create a shallow tree with lots of headings at the same level, or a deep tree with fewer choices at each level?”

For example, here’s a tree designed as shallow and deep:

• diagram of shallow and deep trees

In most cases, it’s best to go with a shallower, wider tree because:

• With many headings to choose from, the user may be able to spot the keyword they’re looking for immediately, without having to click down a level.
  
  
• In a narrow/deep tree, trying to keep the numbers of headings small at a given level sometimes means that we have to create headings that are abstract, and this makes it hard for users to understand what those subsections contain.
  
  
• If the tree is too deep, it’s more likely that users will get lost or discouraged, because they have to do more “navigation work” before they get to the actual content.
  
  

Note, though, that wide/shallow trees can cause problems if they’re too wide:

• A huge number of headings at a given level can make tiring for the user to skim and choose.
  
  
• Lots of headings can make it harder to keep them all clear and distinguishable.
  
  
• Too many headings may make it hard to fit them all in the site’s navigation bar.
  
  

For more on this, check out Kathryn Whitenton’s excellent article on Flat vs. Deep Website Hierarchies.

If you’re working with a project team, you have an advantage in generating ideas for site trees – other people’s brains.

Different people have different backgrounds, different knowledge, and different biases, and if we share our IA research with them, they are likely to come up with new and useful ideas for our site structure.

When we’re working with a project team, we typically do the following:

1. Distribute the results of our research (e.g. findings from our card sort and other related studies).
   
   
2. Meet to review the research and show everyone how to “rough out” a site tree (see below).
   
   
3. Ask each person to take an hour at their desk to rough out 1 or 2 tree ideas.
   
   
4. Meet again to review everyone’s trees.
   We start with “show and tell”, then we discuss the various approaches and pick 2-3 trees that we want to pursue.
   
   
5. Assign a person to each candidate tree to flesh it out for testing.
   
   

For easy collaboration, we use a shared spreadsheet (e.g. Google Drive or equivalent) with:

• A tab for the existing site structure (if any)
  
  
• A tab with a list of the content areas that the site needs to cover (from our content audit)
  
  
• A tab named after each person
  
  
• Later, tabs for the candidate trees that we will flesh out
  
  

• ss of GD spreadsheet with team member’s contributions.

Using a shared spreadsheet means that we don’t have to email spreadsheets to each other, and each person can “peek” at what others are doing to help them get going.

When we “rough out” a site tree, it means that we create a quick-and-dirty site structure in an hour or less.

The point of this is to do the minimum work to convey an idea to others, so we can then decide whether it’s worth fleshing out enough to test. We don’t want someone to spend an entire day creating a detailed site tree, only to have the team decide that they’re going a different direction.

To rough out a site tree:

• We only create 2 to 3 levels of the tree, even if we know there will be more sublevels. We can create the sublevels later if the tree survives our triage process.
  
  
• We don’t get stuck on wording, especially for the lower levels. At this point we’re looking more for variety than exact terminology.
  
  
• We do a quick coverage pass to make sure we’ve accounted for all the content the site will include, but again, if we miss something, we can fix it later.
  
  

• ss of rough trees

Next: Picking candidates to test