The Product Design Process

Tree Testing & Conclusion

Paul Boag

Paul Boag

The Product Design Process

Check out a free preview of the full The Product Design Process course

The "Tree Testing & Conclusion" Lesson is part of the full, The Product Design Process course featured in this preview video. Here's what you'd learn in this lesson:

Paul discusses the use of tree testing to confirm that the information architecture is effective. He also emphasizes the need to prioritize important tasks and ensure that users can easily find the functionality they need in the app.


Transcript from the "Tree Testing & Conclusion" Lesson

>> Then you might think that's a bit of a laissez-faire attitude for creating your sub navigation and organizing stuff. But I will often do a tree testing exercise after I've got my information architecture for my app with all the different features and functionality. And a tree testing exercise basically looks something like this.

So you create a task where you say, where would you find information relating to so and so, or where would you complete this task? And then they can navigate through the hierarchy until they find the page where they think it would be, or the screen where it would be.

And I can then see whether people are navigating to the right place. In terms of obviously those, you can't test absolutely everything in your app like that, any more than about ten tests and people start getting peed off and not wanting to do them. So the things that I tend to test is anything that had a really low agreement score.

In other words, in the card sorting, they weren't sure where to place it, I tend to test that with tree testing. Anything that got put into not sure with a very high percentage of people putting it into not sure, I make sure that I test those. And then finally, if you've got one of your top tasks that you identified, and you've ended up burying it in your information architecture, for whatever reason.

Then I try and test those as well to make sure they can find them cuz we don't wanna make people struggle to find top tasks. To create a top tree test, it's really super simple. You click on Add a New Tree Test, wow, that blows your mind. You give your test a title, you give what is you want people to do.

And then you describe where it is on the hierarchy, on the site and stuff like that. You don't need to watch that video, you get the idea and you can play around with the app yourself. It's got a free tier on it, so it won't cost you anything to give it a go.

When you get results back, they look something like this on your tree testing. And your success score is the key metric that you wanna look at. So how many people have successfully found where that task is on the application? But it's also useful to look at how directly they did that, right?

And if they didn't get it right where they ended up, right, because oftentimes a bit crosslinking can fix the problem if you need to. And also I quite like to look at how long it took them to do it as well. Cuz if it's taking them a long time, then you've got some changes to make and fiddle around with that.

So information architecture is a thing that's often not given enough attention in my opinion within product design. But if there's a problem, you can either move the thing to a different section, or you can just cross-link to it. So there's a little bit around kind of information architecture and how I work with that.

And particularly around top tasks, that's the big one. When it comes to an application, you need to know which tasks are most important to people. So you wanna identify your top tasks and then organize them with some open card sorting. Check the tiny tasks supported by your new information architecture with your closed card sorting, and then finally use some tree testing to confirm that everything's working.

So normally, before I even jump into Figma, or do any prototyping, I tend to start with that. Because if I can get that right, I at least know that people can find the functionality within the app, and that's often half the battle, yes?
>> I guess one year we did a general survey and then we took the top features, and then we basically, sort these features based on what you wanted as a community.

And that was really interesting to see kinda at a high level, where users thought that the priority should be. We didn't end up following it exactly, but still, it was very helpful to-
>> That's top task analysis. You've done exactly it. And yeah, you're right, you shouldn't blindly follow it.

Because there are other considerations, there are business considerations, there are time and effort that goes into it. But just knowing what those main things that people care about is so, so important. So yeah, that's really good.
>> We just had a discussion kinda around feedback and triaging feedback, and how certain companies will search Reddit and find users complaining about certain things and then fix it and-

>> Yeah.
>> They wouldn't necessarily rely on voting, they would just see social as a indicator.
>> Yeah.
>> We definitely do that up Frontend Masters as well, every day I'm searching across all the socials and seeing.
>> Yeah.
>> Trying to find the actual criticism because-
>> Absolutely.

For me, the way that I operate in that is, that's fed into the list of that backlog I talked about. And those things would get pointed and then go into the backlog into that optimization stream of where we can make improvements. So that's kind of how I deal with them but absolutely, it's definitely worth doing.

There is some good apps for that, which I touch on on the other course, which is, if you have a big idea for an app, how do you go about developing the app? One of the things I mentioned and that is apps called Mention and BuzzSumo, which are really good for kind of knowing problems with your competitors apps.

And finding out what people are moaning about them, but you could use it for that social media monitoring as well. Very cool.
>> People are really surprised if I respond to it with my personal account or something.
>> Yeah.
>> I always respond with a business account. If it's just something, hey, totally understand we're working on this or whatever.

>> And people really appreciate, I know I do. If you suddenly get you've had a bit of a moan online, I don't like it when it's like you get this message back from support saying, we're really sorry you feel unhappy about this, please DM us with your complaint.

I mean, I don't know, but to be reached out by someone that actually works on it, and he's genuinely a human person, and he's taken an interest, that's amazing. That's really really good and definitely worth doing, so yeah.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now