We're going to be looking at a couple of testing tools or testing techniques, one called tree testing and the other called first-click testing, which are *admirably suitable* for early design. So, you're working on – you're thinking of how your website should be navigated or you're working on some very rough wireframes or general ideas about how that navigation should be
presented in the context of your project, and you'd like to get some feedback. And these two techniques are really absolutely ideal for that scenario. But, having said that, both of these techniques: tree testing and first-click testing can be used at *any stage* in project development, so all the way from early design through to final buffing and polishing, say, of the navigation framework. If you want to just make a tiny change and see how that affects the site *before* you launch,
then something like tree testing may be absolutely ideal. And one of the real strengths of these tools is that they're pretty isolated in the sense that you're only testing one or two very specific components of your overall solution. So, tree testing in fact is absolutely laser-focused on your navigation; that is all you're presenting, and you're not presenting it with any kind of visual component.
It's presented, it's simulated by the testing tool. So, you just upload a navigation tree that you want to test and you give your participants some goals and off they go; and you're testing now how they understand those words – nothing to distract them; there are no visual distractions at all. But they do lose a little bit of the context that way, as we'll see a bit later on, too. So, early-design testing allows design components to be evaluated *prior* to extensive development efforts.
So, you could be doing this in the first week of a new project. There would be no problem at all in that. It might take a little while to *organize*, but certainly you could be seeing results only a couple of weeks into your project. There are *many* forms of early-design testing. The particular attraction of these is that they are what we call *quantitative* – they produce numbers where we get to actually see some statistics on how people perform in these particular tasks.
Paper prototyping I list as an alternative here. That is not a quantitative process *typically*. We're not actually looking mostly at success when we're talking about paper prototyping. We're looking at a *qualitative* focus, so we're trying to understand what's going through people's minds and we ask them about why things didn't work and what's going on inside their head. That's very similar to usability testing, and usability testing is predominantly a qualitative process.
So, these are almost entirely quantitative; they're done *online*, and that means that we're not really going to be able to get inside our participants' heads, but that is both a benefit and a drawback. The benefit is that we're going to get some hard numbers out of it and it's very quick to do. We will be typically testing with dozens, scores of participants – certainly, 100 participants wouldn't be difficult to imagine. Whereas in usability testing, a day's work is represented by about seven
participants, maybe up to 90-minute sessions, so they are quite different animals from that point of view. And I won't be talking any more about usability testing in this. It was just by way of comparison. And usability testing, of course, as I mentioned is a qualitative technique. The *reasons* that you might consider early-design testing – well, it's relatively quick and inexpensive; done online, primary costs with that are actually *recruitment costs*
– getting people to come and take our studies; so, there isn't the renting of a lab for any kind of qualitative research; there isn't the hiring of researchers; You set up the project; you leave it to run; you recruit participants to it, and you check on your results a few days later. It can be as straightforward as that. Only minimal navigation or visual design is needed; you don't have to have thought things through absolutely to the end of the process.
You can get some really good feedback about what's working and what it isn't from the very earlier stages, and again that's really one of the main strengths of the whole approach in both of these cases. Very effective for early design, and – as I mentioned already – can be used at any stage in a project. And I've hinted at this, but I will now put it in very precise terms that it's a *goal-oriented focus*; in all these cases we present our navigation or our visual design along with some tasks
– a list of tasks that we would like users to try to pursue. And we're looking at how they *perform*; so, that is the quantitative aspect of it. It is purely *what they do*. There is no element of asking them how they feel about it or why they've made those particular decisions – although those are optional extras in some cases. Certainly, the *why* aspect of it can be; but *predominantly* we're talking about the numbers that come out of the end. And that's why we need at least several score participants
– something around the 30–50 mark as a starting point. For existing solutions, you could use early-design testing for identifying problem areas. So, if you've got some problems on a page or with a site in general but you just don't really have a handle on what those problems are, then trying to give people some specific tasks and then giving them your navigation structure may produce some *really* very straightforward feedback on that issue.
You also can use it for collecting data for improving designs, along similar lines; you would try out things that you know people seem to be struggling with or that are really important to your organization's goals with a particular solution and see how people fare. *New solutions* – well, evaluating and improving design elements; it's really more or less exactly the same process, but you might be at the beginning of a new solution, be trying to understand what was good, what was bad about the *old solution*.
Certainly, knowing what worked is a good situation to be in when you're setting off to revamp a design. *Alternatives* – well, I already hinted at paper prototyping, and I've already said that that is primarily qualitative; we're talking about very small numbers of people for a fair bit of researcher effort. But it is different and it is qualitative, so we won't be going into detail about that here. Web app or analytics – the problem there is that we know what people do but we don't really know why they've done it.
So, we might find that people were bouncing between two pages in a website or a mobile app and not really understand *why*. So, we've got numbers that say "There's something going on here" but no way of finding out. So, if you have suspicions that it's navigation-related or the visual design we test with the first-click testing, then we can try that out pretty quickly and relatively cheaply, compared with some other approaches – particularly the qualitative ones, which do tend to be more expensive.
And, finally, card sorting is another technique you might consider. It can be used both qualitatively and quantitatively. And we won't be talking about that in these modules, but you will find information on card sorting on the Interaction Design Foundation website. There's a very extensive encyclopedia article that I wrote about card sorting several years ago, which you should find pretty useful in that respect.