Finding The Sitemap From The Trees: Effective Tree Testing

Finding The Sitemap From The Trees: Effective Tree Testing

So now you know what Tree testing is, you’ve created your first test and sent it to your users before finally digging though the data to discover how users are using your site, so what do you do next? 

Tree Testing won’t highlight all the potential issues with your site structure rather, you should use Tree Testing to help point you in the right direction when you are looking to make some changes to your website. In this post we will provide some tips and tricks that will help you to get the most from your Tree Testing to ensure you get the best overview of how your website is performing. Let’s dive in!

Set a maximum of ten tasks per user 

As outlined in our post, how to conduct a tree test you can write as many tasks as you wish per user/persona group. However be wary of asking a user to complete too many tasks as they will either get bored and skip the task providing you with little to no data or they will become too familiar with your website thereby knowing where everything is, this is known as the Learning Effect (more on that in a separate blog post). Therefore to be able to get a decent amount of data we would recommend creating around six to eight tasks per user/persona for a small website upping that to around ten to twelve per user/persona for larger websites. One to thing to remember when sending out your Treejack surveys, you can limit the amount of tasks that a user can complete so if you do have more than ten then you could always ensure that users get a random selection of ten journeys, this should hopefully allow you to test a range of different tasks.

Beware of give away words or questions

Tree Testing is a very fine balance between making users work to find the information and ensuring the structure is as logical as possible. By including what is termed ‘give away’ words in your questioning you quickly tell a user where to go, skewing your results and providing you with a false result. An example of this might be asking a user to go and find an expenses form and then labeling a page within your site expenses form. Users would then go and find that specific page directly without thinking of where it should be.

Don’t include helper pages or topics

This one might seem peculiar but actually holds some truth to it. By helper pages/topics I mean the likes of Help, Contact and Support pages. These pages shouldn’t be included in the sitemap as they provide users with a get out of jail card. Since users can be lazy at times they will choose the path of least resistance and I have seen examples in our own testing where a user has gone straight to the contact page rather than looking for the information. Removing helper pages helps you to focus users on finding the relevant information within your website.

Write tasks that test what you want to improve

If for example you want to test how easy it is to find a sign up form or service, then tailor your questioning to reflect that without giving the game away. This should help you to discover how easy it was for users to find that specific page or section.

Write your tasks as hypothetical situations or problems

When you write your tasks, write in a natural, plain English style that will help users understand the task. So rather than phrasing a question as “Click where you would locate service one” you could phrase it as “you require support for your I.T. system and need to know what is offered by x”. Keeping things relaxed and conversational will change the question from a click here order to a find the right thing task.

When writing your Tree Testing tasks be mindful of the above points and remember, you may know where things are and what certain phrases mean but your users may not so make it easy to digest and understand. Following these basic principles should hopefully help you to uncover extremely insightful data that will make the experience users have on your site the best it possibly can be.

Happy Tree Testing!


New Call-to-action

Leave a Comment

*Indicates a required field