So far, we’ve talked about “task ideas” – rough jot notes about things we think would make good “find it” questions for our tree test.

Eventually, though, these need to be refined into properly worded tasks for our participants. But what do we mean by “properly worded”?

And how hard is it, really, to write a task? We just need to tell our flock to go look for women’s jewelery, right? What could be hard about that?

OK, here’s the truth - after running scores of tree tests for a wide range of clients, and after reviewing dozens more run by organizations on their own, we can truthfully say:

We're not saying that all their tasks are horrible, but a great many are. And it’s not just first-timers – some people repeatedly put tasks out there that are just not going to give them the clear results they want. Their intentions are good, but they keep making the same mistakes over and over.

Luckily, these mistakes are usually easy to fix. You will eliminate most or all of them by following the guidelines below.

The most common cause of bad tasks, by a longshot, is using “give-away” words that point the user to the right answer. You ask them to find something, and that exact word jumps out at them from the topics they’re looking at.

For example, suppose the task is “Find out who to contact about your warranty”, and these are the top-level topics they see:

• Products
• Support
• About Us
• News
• Contact Us
  
  

99% of your participants are going to click Contact Us, not just because it’s correct, but because the word “contact” matched the task.

We want participants to choose topics because they seem the best choice among alternatives, not because of simple word-matching.

While this seems easy enough to do, it turns out that all of us are guilty of using keywords in some of our tasks (or, at least, in our first drafts of the tasks). That’s because we’re immersed in the site’s content, its structure, and its jargon. Once we’re in deep, it’s how we naturally think and talk about the site, so it inevitably spills over into our task phrasing.

The cure is obvious – we need to avoid those keywords, paraphrasing and substituting synonyms to end up with the same meaning. Usually this is straightforward, especially if we remember to “speak” conversationally, as our participants would to each other.

Here’s an example taken from an intranet tree test:

“You need to get reimbursed for expenses. Find the expense form.”

And here's the tree:

• Library
• Expenses/Reimbursements
  • Rules for claiming expenses
  • Expense forms
  • Who to contact
  • Travel
    
    

Only a card-carrying cretin would get this one wrong, but what about the 99% who got it right? Did they succeed because they thought and decided that Expenses/Reimbursements was the best choice (as they’re supposed to do), or because they simply matched the words “reimburse” and “expense”? Even someone who didn’t understand English could find the right answer here based on word matching. So while we get a high success rate for this task, we still don’t know if this was a result of the clarity of our tree or the wording of the task itself. We haven’t properly “tested” the tree.

It’s easy to solve this one, because it follows a common pattern; the tree uses jargon, and the task does too. If we just change the task to sound more like what a real employee might say in conversation, it might come out something like this:

“You paid for some work-related things on your personal credit card. You need to fill out the paperwork to get paid back.”

Notice that we’ve avoided using the term “reimburse” (easy) and the term “expense” (a bit harder) by replacing them with synonyms. The revised task is a bit longer, but it’s still clear and doesn’t give anything away. Now, participants will have to make their own connections by thinking, not by just spotting the matching word.

We also want to avoid matching sequences between our tasks and the tree. This happens when we phrase a task so that it uses the same order of words that the tree’s headings use.

For example, an IT department used this task in their testing:

“For a fixed asset such as a laptop, how would you request an upgrade?”

Their tree:

• Fixed assets
  • Computer equipment
    • New purchases
    • Upgrades
    • Warranties and repairs
  • Furniture
  • Heating/cooling/ventilation equipment
• Non-fixed assets
  
  

This task achieved a high success rate, but like the word-matching discussed above, we can’t tell if this success was because of the clarity of the tree or the wording of the task.

In this case, the word-matching was made worse by the sequence-matching of fixed assets, computer equipment (laptop), and upgrades. Because the task used the same sequence of terms that the tree used, we gave the answer to our participants, so we can’t trust the resulting high score.

Luckily, sequence matching is easy to fix; we changed the phrasing of the task to use a different sequence, and used a more everyday tone:

“You want to request more memory for your company laptop.”

Another common task mistake is ambiguity – wording a task so it could be construed more than one way. You may think the task is clear (after all, you wrote it), but will all of your participants understand what you meant?

Consider this example from an online-banking study:

“How would you get notified when your account balance is low?”

We thought this task wording was fine – until we piloted it with some members of the project team.

• We intended the task to mean “How would you set up a notification?”, and half the team thought the same thing. The answer was in the Setup section.
  
  
• However, the others thought it meant receiving the notification itself, so they went to the “Secure mail” section.
  
  

Once we discovered the problem, of course, it was easy to fix. We revised the task to:

“How would you arrange to get notified when your account balance is low?”.

This meant the same thing to everyone, and we managed to avoid using the give-away phrase “set up”.

Avoiding ambiguity is hard, because it doesn’t usually seem ambiguous to the writer. The best way to avoid ambiguity is to do the simple paraphrasing exercise we describe below – see “Test-driving your tasks” on page ~.