Interview Protocol Assignment Handout

Before you conduct your semi-structured interviews, you will need to prepare an interview protocol. In this assignment, you will write and submit the interview protocol for your interviews. Refer the Sample Interview Protocol handout (Sept 2.4) to get a sense for what is expected. (Note, though, that that protocol was developed for a 15-minute interview. You will be conducting 1-2 hours of interview with observation.)

It is recommended that you work on the interview protocol in a single document so that you can edit and organize freely, and then once completed, cut and paste portions of it as prompted by the online assignment.

Write an introduction script. Generally, this will apply for all the protocols, and you can base yours off of the Sample Interview Protocol handout that is provided. The introduction script should include…

A self-introduction

The purpose of the interview

What you will do during the interview and why

Expected duration of the interview

Confidentiality statement. The nature of this will depend on the user needs assessment and whom you are conducting it for, but for this course, just relay general remarks to the extent that you will not attach personally identifiable information (such as their name) with any final outcomes of the project.

Voluntary nature of the interview. Participants should be aware that they can quit or cancel the interview at any time.

How you will follow up

Permission to make an audio recording of the interview, if possible

Formulate one or two overarching questions. These will be the core questions you keep in mind throughout the interview. You should not have more than two overarching questions for your mini-project. (In bigger projects, you might have a few overarching questions, but even then, it is helpful to keep it to one or two.)

Write 5-10 core questions (4 is too few; 20 is too many). Tips for core questions…

Where possible, ask interviewees to talk through concrete instances, rather than asking generic, summarizing questions. “Tell me about the last time you performed this process,” is better than, “Can you tell me how this process typically goes?” (You can ask the latter kind of questions, too, but don’t forget to ask about specific instances.)

Some of the core questions should prompt the interviewee the relevant work flow and talk through the process as you observe.

For the core questions, cluster them by theme. Think about the ordering of the clusters, and also the ordering of questions within each cluster:

Topics should flow in a way that is easy for interviewees to follow.

Questions that are more open-ended should precede more specific questions about the same topic. This allows the interviewee to respond first with the way they think about the topic.

Questions that might be sensitive should be asked toward the end of a cluster, or even toward the end of the interview. If a question might erode rapport with the client, you want to do it later in a cluster of questions or later in the interview.

Sometimes, it’s OK to say, “Let’s switch to a different topic.”

For each core question, write several follow-up questions. (Your peer graders will be expecting an average of 3 or more follow-up questions per core question.) Include them under the core question in indented form, or as a bulleted list. These questions should help you do follow up, but if your core questions are good, the respondent will cover some on their own, and you may not need to ask follow-up questions explicitly.

Follow-up questions are meant to fill holes in information, or to hear more about interesting issues that the interviewee raises. The goal is either to make sure the interviewee has really addressed the core question to your satisfaction, or to follow up on leads that you may not have anticipated, but which are relevant to the problem. Throughout the protocol, avoid these common errors:

Including too many closed-ended, short-answer questions. If most of your questions are closed-ended, you will have a short interview in which you learn very little. (However, it’s OK to have some short-answer questions, especially during warm up, or when you need concrete information to ask an open-ended follow-up question.)

Asking about basic information that you could have easily found out through other means, such as an online search.

Asking irrelevant questions that don’t contribute to the overarching question, or which aren’t pertinent to your understanding of the problem.

Not asking about specific, concrete instances. It’s OK to have some questions that ask interviewees to summarize what they know, but ask such questions after you’ve asked them about a concrete instance of the situation. (People often do not summarize accurately, and summaries in interviews are not as credible as concrete information. It’s your job to summarize during analysis.)

Adopting a tone that could be interpreted as doubting the interviewee, or evaluating the interviewee’s competence. “Why isn’t this a problem you can solve by looking up online help?” could sound accusatory. A better way to phrase this question is, “When you encounter obstacles like this, how do you go about addressing them?”

Asking leading questions that include an assumption that may not be true, or which influence the interviewee to answer in a particular way. Examples…

“Is it because of a bad process that this task is difficult?”

Instead, try: “What do you think makes this task difficult?”

“Isn’t this a poor user interface?”

Instead, try: “Is this user interface good or bad?”

Even better: “What do you think of this user interface, and why?”

Write a conclusion script. Ask them if they have any other things to tell you. Let them know the interview is over. Thank the interviewee. Let them know what will happen next. Again, feel free to use the Sample Interview Protocol as a template.