With any decent-size tree, the problem is not coming up with enough tasks to ask; it’s cutting down a large number of initial task ideas to a manageable set that answers the your main IA questions you’re asking.

Just as in conventional usability testing, we concentrate on the most common and critical tasks, plus those that test parts of the site that we’re most unsure about. But we make sure we’re not hitting those too hard, lest we miss a problem elsewhere or “train” our participants too well.

One of the basic tenets of good design is to make common functions easy. In IA terms, this means making frequently - looked-for things easy to find.

So we definitely want to include tasks that represent should start our task list with the common things our users would be looking for or doing on our site.

If you we have existing user research at hand (surveys, usability-test results, analytics, search logs), then coming up with a list of ideas for common tasks should be easy.

•  example

We also want to include tasks that cover things that users don’t need often, but need fast if the situation arises.

For example, on a mobile phone, you we may not ever dial your our country’s emergency number, but if you we do need to, it has to be really easy to find.

On a website, an equivalent case might be resetting your a password. Users shouldn’t have to do it very often, but if they do, it needs to be easy to find.

We definitely want to include tasks that test areas of the site that:

• Have been substantially reorganized or renamed
  
  
• Have been argued or worried over by the project team
  
  
• Have several ways they could be structured
  
  

This is one reason why we recommend working in a spreadsheet format. As you ponder, discuss, and argue about various parts of the tree (or compare various tree ideas), you can remind yourself to test those parts by adding a note in the Task column:

•  example

Image Added

If this mantra of “common, critical, and suspect” tasks sounds familiar, that’s because it is. These are often the same tasks that we focus on in traditional usability tests.

The good news here is that, if you have run usability tests on your site, you can recycle some of those user-test scenarios into tasks for tree testing, especially any scenario that involved finding something on the site.

If you’ve done a card sort as part of your IA work (as described in The research phase in Chapter 3), you’re already halfway to creating your list of tasks for tree testing.

When you prepared the card sort, you picked out representative content from your site and created each item as a card. Now that you’ve created a tree where all that content is going to live, a subset of those cards can be reworded into tasks for your tree test.

•  example

Image Added

Note that in card sorting, you typically create 30-50 cards, whereas in tree testing, you’re normally dealing with far fewer tasks. In this case, it’s mostly a matter of choosing which of your cards answers your tree-test questions best, and gives you the coverage you want for the tree. And you’ll also probably need to reword those cards into proper tasks, as covered in Writing a good task later in this chapter.