Getting your tasks right is vital for gathering useful data. You want the tasks to reflect how your users might naturally approach your website, and you also want to make sure you don’t give the answer away by using the same language that’s in your tree. Your tasks will be linked to your tree testing objectives.
This article describes why we recommend you:
set a maximum of 10 tasks
write tasks that test the part of your website you want to improve
write tasks as hypothetical 'scenarios' based on your typical visitors
use different language than the labels on your tree.
Set a maximum of 10 tasks
Each task will give you data on a different part of your tree, so match the number of tasks to the parts of your tree you want to test. As each task is scored individually, you can have a few as one task if you have one specific part of the tree you want to test.
We recommend a maximum of 10 tasks per tree test for 2 reasons: More tasks might mean fewer participants complete the entire test. And you run the risk of people becoming too familiar with your tree, which would bias the results for your later tasks.
If you do set more than 8 or so tasks, we recommend selecting the option to randomize the order the tree is presented to people. Then for each task, people will see the labels arranged in a different order.
If you want to gather more data from a test on the same tree, you could set up a separate test and either recruit different participants, or ask the same people after some time has passed.
Write tasks that test what you want to improve
Take the evidence you gathered when setting your objectives, and write tasks that enable you to improve each one.
For example, you might know that your contact centre has been inundated with calls asking where to find ‘Form X’. If you therefore have a task that says “You need to complete X application, and you want to know if you can do this online”, the data you gather will tell you:
how many people actually found Form X
how long it took them to find it
the path they took, and whether or not they had to click back up the tree.
Write tasks as hypothetical ‘scenarios’
You want your tasks to mimic the thought a person might have when they visit your website. Write in a natural, plain English style and introduce a hypothetical scenario for people to bring to mind.
Instead of writing “Click where you think you’d find our office” you would write “You’ve booked a meeting with one of our staff, and you want to find out where to go.” Keeping the tone conversational will make the task less ‘Click the thing’ and more ‘Find the right thing’.
Use different language than the labels on your tree
People will take whatever language clues they can get from your task to make it easier for them. So if you have the phrase ‘application form’ in your task and on your tree, you risk ‘giving away’ the answer. There’s 2 problems with this.
People who select the correct destination might just be matching the phrases rather than actually deciding the information is correct. If tasks that include the same language as your tree score highly, you can’t infer a lot from the data.
And it’s impossible for our labels to mimic the language each of our users have when they visit our websites. Here’s an example of what we mean.
Let’s say you have a link on your website labelled ‘Application form for X’. And 3 people see that link and think “Yes, that’s exactly what I need!”. Those 3 people could have had the following 3 questions or tasks in their minds:
What do I have to do to get funding for this project?
Can I send them my information online, or do I have to call them?
What kind of evidence do I need so I can apply for this funding?