Interview methods

Hi, I'm Lorenz and welcome to Analysis practice!




In the analysis phase we have different methodologies at our hand. In this lesson, we'll show you how you can gather information on the users, their goals and the usage environment. Let's start with interviewing our potential users.




One popular approach is to conduct moderated discussions, which are called focus group interviews or focus group discussions. Since you have several conversational partners at once, who also should interact with each other, it is very important to be well prepared. You already should have knowledge about the topic you are discussing and an idea about what you want to know. Therefore, you should prepare a guideline for your interview with questions you can ask your participants. Formulate the questions openly so a discussion can emerge. During the discussion you are a moderator, not a participant, thus, you ask your more or less general questions and then let the panelists answer and discuss. It would be good if you also have more detailed questions on a topic in case the participants digress or the conversations comes to a halt. But remember: even when asking detailed questions you should never be suggestive. The entire discussion should be recorded on tape, since it is very hard to protocol the conversation and moderate it simultaneously. And even if you have an assistant, it is impossible to capture every single sentence. Since the interaction between the panelists is also very interesting, the manner participants say something can also contain valuable information. Your record should be transcripted afterwards, so you can analyze the transcript systematically. Besides the interaction between the participants, one further advantage of the focus group is that we explore different opinions in one discussion and also directly gather comments on these opinions by the participants.




Another way of gathering information is the expert interview. This is a more classical face-to-face method. As the name suggests, our interview partner is not an average user, but an expert in a field you're interested in. In this way, you can build up insider knowledge non-professionals do not have. Before we choose our expert, it is wise to define our field of interest and why we need which kind of expert. Our choice should then depend on the insights we want to gain. In the preparation phase, we also should generate a guideline questionnaire divided into subtopics. Our questions should be open and therefore allow the expert to answer broadly so we can find interesting information where we were not looking for it initially. Our guideline should be structured in such a way that the most important questions come first, because the interview might run long, so we don't get to our last questions before the time is up. As already mentioned, the participant should have the freedom to answer broadly, but we also should try to keep him within our topic without disturbing the natural flow of a conversation. As in the focus group discussion, our interview should be recorded, transcripted and analyzed systematically.




The problem-centered interview is also a face-to-face approach. Our participants are people who are familiar with a specific problem that we want to solve. Here, we prepare mainly questions for the beginning and the end of the interview. The interviewee guides us to the bottom of the problem. Consequently, we try to evoke storytelling. In this way, we are able to understand the problem from its beginning. As it is a flexible way of conducting an interview, we might have to ask some ad-hoc questions appropriate for the participant's story, which cannot be prepared before the conversation.




Another form of interviewing is the contextual inquiry. This method allows us to gather more than statements but also information on the behavior and the environment of our users. Before we start, we have to decide on which information we want to gather. In this way, we don't get distracted by unimportant information and we can focus on our research topic. The contextual inquiry takes place in the natural environment the user uses our product in or will use our future product. While conducting the inquiry, we observe the participant and ask questions. This gives us the opportunity to find out what factors influence the usage, how users interact and what they think while interacting with a product. After the contextual inquiry we analyze the statements as well as the behavior of our participants.




In the preparation phase of the UX laddering we gather questions serving this particular method of interviewing. We ask our participants about attributes they associate with a specific product. Each of these attributes has a consequence for the user, for example, the attribute of a mobile phone could be that it has a good camera, then the consequence is that the user is able to take photos representing the reality with accurate colors. The consequences of the attributes can then lead us to the participants' core values. In our example, the core value could be that the good camera gives the participant the feeling to be able to conserve memories very well. Asking "why?" questions repeatedly can help us getting to those consequences and core values. For the analysis of our data we can use the hierarchical value map.

Who to interview (see Cooper et al., 2014, p. 46)

• What different sorts of people might use this product?
• How might their needs and behaviors vary?
• What ranges of behavior and types of environments need to be explored?

Interview tips

• Transparency/ traceability is important
• Record the interview in order to assure conclusions can be reproduced
• Be curious but reticent
• Your own opinion should not be evident to the interviewee
• Don’t ask suggestively
• Ask open questions and listen actively

Observation

Sometimes, it's advisable not to get actively involved into the process of analysis. This is where observation techniques come in handy. One popular technique is the master-apprentice model. The first principle of the model is to observe the users in their natural environment. This way, we do not only get insight formulated directly by our user, but also gather information on the context the product is used in. The second principle is to create a relationship between the researcher and the user that follows the structure of a master-apprentice relationship. The researcher is the apprentice and the user is the master. When using the master-apprentice model. it is crucial to interpret what the user is saying, meaning reading between the lines, since sometimes there's a hidden message when a user talks to us. It is also important to focus the conversation. Don't get me wrong - it's beneficial for us if the user makes comments that seem uninteresting in the first place, since these comments sometimes are very insightful when analyzing the data, but it's also important to get the conversation on track again when the user moves off topic too far.




When we want to observe our users, we can choose from different methods. There is the control observation, which resembles an experimental setting and there is the naturalistic observation, which consists of observations in the user's natural environment. The participant observation is a sub-type of the naturalistic observation, but with the difference that the researcher is not an uninvolved listener but becomes part of the group he is studying to gain insights to.




Before recording data, we have to decide which technique we use. We could choose the event sampling method which is defined by only recording specific events or specific behavior of our participants. Any behavior different from the predefined one is not recorded at all. The time sampling method says that we only record data at a specific time or time frame. Everything that happens before or after this predefined period is not recorded. The third method, the instantaneous sampling method, is defined by only recording predefined moments.




When it comes to the roles the observer can take, we have different possibilities and can be creative. This boils down mostly to how distant the observer is to the participants both psychologically as well as physiologically, but it's very important to choose the role that is most beneficial for answering our research question. As you can see here, the researcher can be detached from the observed group but he could also be a group member and act as a part of the group while observing. We could even choose a participant to be the observer. Another very exciting way of observing is the method called "complete participant", in which the researcher acts as part of the observed group without the group even knowing that there is a researcher or an ongoing observation.




Diary studies are very helpful if we want to gather information on the usage behavior in terms of times and frequencies of usage. Users log their actions and activities and thus enable us to learn a lot about their usage habits, the usage environment, users' motivations for the usage and even changes in their behavior. As you can imagine, this is some effort for our participants and therefore it is advised to recruit dedicated users when we're fast enough to analyze our data. Immediately we're even able to ask follow-up questions based on the user's diary entries. If you choose to conduct a diary study, you can take a deeper look into this slide and click on the link below the video where this technique is described in greater depth. Here, you see the most important steps regarding the preparation, the briefing of the participants and the other steps you have to take. As you see, it is an elaborate technique but you might gain insights you would never gain just conducting a face-to-face interview.

Analysis

Well, since we're talking about analysis in this section, we finally come to the analysis part of this practice lesson. In short, after you have generated data, how do you process it? Hierarchical Task Analysis helps us understand problems users might face while conducting a specific task. To achieve a goal our users normally have to take several steps, which we can define as sub-goals. For the task analysis, we analyze all actions the users have to take and the associated sub-goals in the correct sequence. The outcome of such a task analysis is often a diagram, which depicts all steps users have to take to achieve their goal. The goals are divided into sub-goals and as you can see, it is important to maintain the real sequence of actions. Such a diagram can help us find the problems users might have when they try to achieve a goal by interacting with a system. We provide a link in the description of this video for further material on the topic.




Now let's get to a method which is very useful and popular: creating personas. The nice thing about personas is that we can harvest the fruits of our efforts now. All the information we have gathered on our users now becomes crucial. The work we've done so far will lead to a persona. Will it be an Alessandro, who loves to go fast, or will it be a Marge, who appreciates safety and comfort? As you can see here, focusing on everybody's needs at once can lead to a product not really usable by anybody. Personas help us determine who our products shall be designed for. They help understand the goals users wish to achieve. Furthermore, they make it easier to discuss our product with other developers and stakeholders, as the personas are more concrete in comparison to a vague target group with different and sometimes inconsistent demands. It's like talking about a real living person which can also serve us to evaluate whether a product is effective and assists the user the way it should. As already said, when we speak about a persona it would be best if it feels like talking about a real person. Therefore, our persona needs details, personal information like gender age and personality characteristics. Is our persona rather thrill-seeking like Alessandro or does she like it more comfortable? What does her life look like, does she have a job and if yes what does she do for a living, does she like it? What does she do with her spare time and what are her goals and wishes? You see, you can be very creative here, but be careful: every single characteristic should result from your research into your potential users.




While constructing personas it's important to understand the difference between a stereotype and an archetype. A stereotype is a commonly known but oversimplified image. This leads to seeing an idea or group in a rather exaggerated, close-minded way. In contrast to this, an archetype is a typical image which includes specific characteristics and fits fundamental human motives. This is exactly what a persona should look like: a prime example and reliable realistic representations for a target group. Insight for this needs to come out of quantitative or qualitative research or web analytics rather than preconceptions.




Well, here are some basic rules when it comes to personas. As you can imagine, we speak of one person when we say persona, so do not describe a group. Use archetypes not stereotypes and, as already mentioned, but i will say it again to emphasize the importance, your persona should be based on your collected data, the information you gathered in previous steps not only your beliefs and assumptions. Also, do not try to describe the average with your persona. It is more exciting and useful if you describe a rather extreme character.




Next, we have the quote of all quotes regarding user-centered design or user-centered perspective. It is often used by critics in terms that the users are not always right. Allegedly said by Henry Ford - though probably not - it still captures the essence of what he thought, we shall see if he was right. If you look at these pictures you can imagine what insight we're aiming at. Sometimes, it's not the most important thing what users say they want to have, but what they want to achieve. Since it could be that our users are not very creative in coming up with ideas, we should do the work for them and for this purpose what we really need to know to help them are the jobs to be done.




When we look at the jobs to be done, we have to keep in mind that there are different aspects one job can have. There are functional, social, personal and emotional aspects connected to a task. Moreover, sometimes there's not only the main task, the job we're talking about, but also related jobs to be done, which also have the functional, social, personal and emotional aspects. If our job is for example brushing our teeth, our goal is having clean teeth. The functional aspect of this job is removing foreign particles, while the social aspect could be that we want to be perceived as having white teeth. The related job to be done could be not wasting too much of our time getting clean teeth, therefore, the functional aspect here is being efficient and the social aspect would be that we want to be perceived as a person who uses products of high quality.




What are the differences between personas and jobs to be done? The most obvious one is that we put our focus on the user and the potential differences between them when we create personas, while our focus is really on the task and when we work with jobs to be done. But in comparison to the task analysis for example, we put less focus on the single steps the users have to take to achieve their goal.




A scenario is defined as a specific story to construct and illustrate our design solutions. They are the first step we take when we are about to make designed solutions. We create a narration with our personas in the leading role, containing the problem the persona faces as well as the solution. Here are two examples for scenarios.




As you can see, we have a persona Vivian and a job or tasks she has to solve. The narrative also contains the actions Vivian can take to achieve her goal. Our design solution is then the product Vivian could have used in this story to solve her problems. In a scenario, no detailed information on the interaction with a potential design solution is described, while use cases are part of the required catalog, defining the system responses to our user's actions.




A scenario shows the bigger picture by storytelling and can be divided into several use cases. Use cases then consist of the goal of an action, the trigger of an action, for example a user interaction, and the single steps the user or the system takes to achieve the goal. As you already know, users or their tasks are not the only important aspects for us, but also the context in which the users fulfill their tasks.




The context of use analysis helps investigate the conditions under which our product is used and the factors that might influence the usage. Therefore, we have to include in our analysis the user, their goals and their equipment, as well as the environment. Not only the physical, but also the social environment is of interest, as, for example, the presence of other people might have an effect on the interaction with our product. When we want to evaluate our product, sometimes it is wise to also conduct the user study in the natural environment to increase the external validity.