Thanks Jared.

When other tasks are introduced are these tasks based on what the business may want to find out? i.e. to meet a business goal.

Ideally, when you mix other tasks in, you can continue to use the language and objects that came out of the interview. What you want to avoid doing is jumping from scenarios where it’s based on elements the participant introduced to elements based on fictional tasks (such as, “Pretend you’re thinking about opening a new account…”).

However, there may be functionality the business wants to discover that doesn’t come out during the interview. In that case, you have to enter the land of fictional tasks and things are back to the ole’ scavenger hunt tasks. In these instances, I always find it interesting to ask the participants how they feel about the tasks.

In our experience, however, it’s risky to put too much weight behind their answers, since participants will do their best to please you and may imagine instances of use that would never really occur. Instead, if these tasks are really important to the business, I’d rather increase the diligence of our recruiting efforts and find people who are truly passionate about doing those things. If recruiting can’t find them, maybe the functions aren’t as important as we thought.

Paul asked:

It strikes me that these descriptions of interview based tasks deal with eliciting the kind of information you might reasonably expect to uncover during the user research phase. Do you have examples where the interviews at the usability testing stage uncovered information that you were unable to discover (for whatever reason) during user research?

The way I view usability testing of any type is as a tool, like a hammer. So, I wasn’t talking at all about “phases” when talking about interview-based tasks. I was only talking about a variant on the tool.

Frankly, I don’t really know what the “usability testing stage” or the “user research stage” are. In my world, usability testing is a type of user research, neither of which have stages. The way you talk, it’s like a carpenter saying there’s a “hammer stage” and a “saw stage”.

Part of our job is to think about the information we need right now and determine what tools will garner the best results. Interview-based tasks are best in situations when we don’t know how or why people use our designs, making traditional tasks difficult.

Feel free to use them in whatever stage makes the most sense.

2 questions:

1. When other tasks are introduced are these tasks based on what the business may want to find out? i.e. to meet a business goal.

2. By introducing other tasks (in and around the “interview based tasks”) have users commented in the research sessions as to whether these tasks are actually something they would do on the site?

Suggest that sometimes tasks the business want users to complete and what tasks the users actually value can be quite different.