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 our main IA questions.

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.

Common tasks

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 should start our task list with the common things our users would be looking for or doing on our site.

If 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.

Critical tasks

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, we may not ever dial our country’s emergency number, but if we do need to, it has to be really easy to find.

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

Tasks that exercise “problem” areas

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 we ponder, discuss, and argue about various parts of the tree (or compare various tree ideas), we can remind ourselves to test those parts by adding a note in the Task column:

Open

Borrowing from usability tests

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 we have run usability tests on our site, we can recycle some of those user-test scenarios into tasks for tree testing, especially any scenario that involved finding something on the site.

Borrowing from card sorts

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

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

Open

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

Next: How many tasks?