Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »


 

Collecting task ideas

As we come up with ideas for tasks, it’s important to track them against our tree. We jot down our task ideas in our spreadsheet, in the Task column:

 

In this first pass, just get all your ideas down quickly.

  • Don’t sweat the wording yet. At this stage, you’re just compiling a list of task ideas, some of which you won’t end up using. Trying to fine-tune wording now may be wasted effort, and it will slow you down early in the process.

  • Don’t worry about coverage yet. If you come up with 5 task ideas for a single small area of your site, that’s OK. It means you’ll have 5 candidates to choose from later when you’re trimming your task list. And if you don’t have any ideas for a given section, that’s OK too – you’ll get a chance to fill that in when you check task coverage later.

  • Get everyone involved. If you’re working with a team, split up the work among you. That makes everything go faster, and gets everyone engaged with the testing. This is particularly easy if you use a shared online spreadsheet.


Refining your task list

After you’ve taken a first pass through your tree, either by yourself or with others contributing too, you’ll likely come up with too many task ideas. This is a good thing, because you can then refine your task list down to a smaller number of focused items.  

To pick the winners for your task list, look for:

  • Tasks that test your stated goals. When you first planned your tree test, you wrote down the top things you wanted to find out. How well does each task idea answer those questions for you?

  • Tasks that are the most common, critical, and suspect. See Which tasks to include? earlier in this chapter.

  • Tasks that provide good coverage for the parts of the tree that you want to test. See Checking coverage below.

Be sure to mark your task ideas to show which are to be kept and which are not to be used. For example, you could highlight the chosen ones in green, or you could leave them unmarked and highlight the not-chosen ones in red. It doesn’t matter which method you use, as long as you’re consistent (and you include a legend so that you and other can understand your method later.)

Using the spreadsheet method, we find it’s better to mark tasks as deleted (e.g. using strike-through or a red highlight) rather than delete them outright. That way, if we change our minds later, we can reinstate a task that we initially “crossed out”. In the example below, we’ve highlighted the chosen tasks in green and struck out the unchosen tasks:

 

Checking coverage

When deciding which tasks to include, we also want to keep an eye on coverage - which parts of the tree we’re testing, and which we’re ignoring.

It’s not usually feasible to test every subtree of every section of the site, and usually it’s not necessary either. For example, if participants can find the specifications for product A in your site (by looking in the Products section, say), it’s safe to assume that they can also find product B’s specs in the same section.

Once we’ve created tasks that cover the most common, critical, and contentious areas of the site, it’s a good idea to pull back and see which parts of the tree are covered too much or too little.

  • If you are using the spreadsheet method to refine your tree and write your tasks, checking task coverage is simply a matter of scrolling down the tree and looking for entries in the Task column. You can see which sections of the tree are “covered” by tasks, and which aren’t.

  • If your tree-testing software checks coverage for you, activate that feature and see where the gaps are.
     

If you find gaps in coverage (and you likely will), you may want to change up your tasks a bit:

  • If a given section is particularly important to test, you will want at least one task for it, and maybe even two. If you add too many tasks to a given section, however, participants may “learn” that part of the tree better than they would during a real visit to the site, and skew your results.

  • If a section is not important to test (e.g. it worked well in the past, and you’re not changing it now), it may be OK to have no tasks for it. Note, however, that if you change the tree around it, this might affect how users then navigate this area of the site. If you have any doubts about this, consider adding a task to make sure.

Keep in mind that some of your tasks may have several correct answers in different parts of the site (or at least several places where you suspect participants will look). If you’re using a spreadsheet to track tasks, it’s often a good idea to copy your task ideas into these alternate slots too. We typically use some kind of styling (e.g. italics) to indicate that these are references to a task mentioned elsewhere in the tree.



Next: Different tasks for different user groups

 

  • No labels