Hello. This part of the lecture continues the discussion about situations in which you need to intervene and ask questions or assist participants with something. The common situation is when a participant thinks that she has completed a task, but according to the criteria of the task completion, she hasn't. In case there are some dependencies among test tasks and you know discussing the problem will affect a later task performance, don't do anything. Just describe everything in your notes and move on, because you're interested in two things. First, will the participant understand that the problem exists? And secondly, how will she cope with it? If there are no such dependencies, ask her to check out whether she has successfully completed the task. As we already discussed in the lecture about different kinds of problems in the previous week, participants may ask you for a new feature. No matter whether this feature is outside the scope of your app or not, carefully listen to what the participants are saying. It's important that they know that you hear them. There are participants that constantly ask for approval of performed actions. Instead of providing the approval, start a conversation by asking, "do you think you did it right or wrong?" Then politely remind them that you cannot answer these kind of questions. Sometimes participants ask what to do next. It doesn't automatically mean that there is a usability problem. You can figure it out why they do that by asking a simple "what do you think?" Many people just aren't confident enough. The situation of usability test is new for them. As a result, they are afraid to do something wrong. Just remind them that there are no right or wrong ways to perform the task, and that you are interested in how they will perform it. If it is an interactive prototype, it's pretty normal that a participant will face unimplemented parts of an interface while looking for a way to complete the task. You don't have to create a fully functional prototype for testing. It's enough to have only those parts of the interface that are covered by test tasks. In this case, just explain to the participant how it would look like and continue on. Don't make a big deal of it. In case of software back in a fully implemented app or software prototype, try to repair it, but don't show the participant how you do it. The idea here is not to reveal information that may affect the participants behavior. If it's not possible to repair the app, stop the test. Don't forget to debrief the participant and give her the promised reward. After all, she did everything that you asked her to do. There are participants that blames themselves if they think they did something wrong. If that happens, remind them of the value of the difficulties in understanding how the product actually works. Encourage them to freely explore areas without concern for looking good. Sometimes the performance of a test task makes a participant feel uncomfortable. It's okay to change the task a little bit or even skip this task for the participant. In the case where a participant thinks that the task is not realistic, use these moments to learn more about the usage context, ask for additional information and reformulate the task with the participant. I don't mind repeating that it's not a big deal to change your test plan in the middle of the test. All right, we are done with our brief overview of situations we need to intervene. I'm pretty sure that you understand this, but I will say that those tips we examined are only starters of a conversation. To figure out causes of some problems, you will need to ask follow up questions depending on the course of your conversation with a particular participant. While asking these questions, you should follow the rules that we were talking about in the lecture titled Ethnographic Interviews: Preparing for The Study. Here, I'd like to add a few more rules of thumb. As I said earlier, the situation of a usability test is new for participants. Despite all informality of guerrilla studies, participants may worry and your job is to make them feel at ease. Humor helps with this. As Rubin and Chisnell note in their book, if participants having fun, they are more apt to tell you what is really on their minds. But make sure that participants understand that you are not laughing at them. Despite the fact that any user interface intends one or several ways to perform a task, never tells participants about right or wrong ways of performing the task, as well as about behaviors of other participants. It will immediately make them think that they did something wrong and will compromise results for this test task. If you have some interpretation about the cause of a participant's behavior, it's awesome. But there is one danger related to it. You may suppose that your interpretation is the only reasonable explanation for what just happened and ask that participant nothing. Or you may ask about the event, but formulate the questions so as to seek confirmation of your interpretation. In the second case, the participant may agree with you even if it wasn't so because of many reasons. Participants do not care so much. They are not good at reflection, etc. Neither your silence nor seeking confirmation are a notion. The best strategy is always to assume that you know nothing and ask open-ended questions, as we discussed earlier. If you made a mistake, continue. Don't make a big deal of it. Moderating usability test is a skill. You should work on it to become better. For this occasion, I prepare the lecture dedicated to that single topic, how to become better in user research that you can find at the end of this week. It contains the whole bunch of advises that will help you to incorporate learning into your practice and develop constantly. The last thing I'd like to touch on in this lecture is the content of your notes. On this slide, you can see the approximate list of things that are worth writing down. Most of them we've already discussed. I'd like to draw your attention to the last two items on this list. Don't forget to write down whether a participant has completed a task successfully or not, plus all instances where you offered assistance. Despite the fact that you cannot assess the effectiveness of the app's interface design having data of five participants, it will help you later to assess the severity of problems. If you come up with some design idea that helps to solve a previously discovered interaction problem right in the course of a test session, sketch it as fast as possible and leave it. You may discuss it with a participant after the session has ended. There are situations where participants themselves suggest solutions. Even if the solution is no good, carefully listen to the participant and ask why she suggested exactly the solution. It can possibly help you to learn more about the problem than the solution is intended to solve. Plus it makes you look better. You care about what participants are saying. Thank you for watching. See you in the next lecture.