Activity 10.2 - Contextual Interview
Jerry's Coments
A fundamental feature of the contextual interview is
being in the context where the action takes place. There are some gaps to fill here, if we are designing something that does not exist, rather than an upgrade, redesign, or reinvention of something which already exists. The interviews discussed in Chapter 7 were characterized as 'structured' or 'unstructured', but in either case were not in the context of the activity subject to design. It is also presumptive, but not boldly stated, that in the 'structured' or 'unstructured' interviews, the interviewer must come in with some questions in mind. The contextual interview would be [or at least could be] somewhat more loosely structured. "Go in there and see what is going on."
I was involved earlier in such a 'contextual' design effort. Going in I had only the vaguest idea what was needed or how the [then paper based] work was done. The 'interview' lasted about three weeks and a lot of the time I was not 'questioning' but rather watching some people at work. The ultimate end-users of the product we were to build were limited in number. The task to be automated: Scheduling and rescheduling spacecraft ground support. The users, all employees of Godard Space Flight Center, were about six people 'upstairs' who were scheduling 'next week' and a somewhat larger number 'downstairs' in operations who were doing real-time rescheduling as necessary. Because the upstairs group was fully involved in scheduling and the downstairs folks were doing a bunch of other things, it was more 'compact' to observe the upstairs people. This was also indicated because of need to be sure we had a correct understanding of the business rules that applied to the advanced scheduling task. The tasks to be implemented in a computer system were being carried out by one set of users in the United States. It may be presumed there was another group somewhere in the Soviet Union, but they were not on our 'potential customers' list.
I was the one who did this. I watched people who were developing schedules with: 1) a knowledge of the business rules, 2) a priority list, which said which spacecraft was considered first, second, and so on. [The existence of this priority rule was critical to the manageability of our task.] 3) Large sheets of graph paper, and 4) Many colored pencils. The critical part of this observation was description of the business rules, which were understood by the workers, but to a large extent not written down.
I cannot imagine a way that an interviewer could have known enough to prepare the questions for interviews 'off-site' [of the sort described in Chapter 7]. Our group was selected and given a 'Sole Source' contract because we had provided some graphic scheduling aids for the U S Air Force, but the ground rules and output products were so different, as was the computing environment, that we had to start from the beginning to understand their needs. The initial interview questions were: 1) What are you doing here, and 2) What are the rules governing the way you do it. If they had been asked the first question, the answer would have been too brief to be of much use. The answer to the second was probably one which they could not have enunciated in any adequate way. After watching, a report was written, describing the activity observed and the conclusions about significant aspects of the tasks for implementation of computer support. The customer requested some changes in the description. Another observer noted that the requested changes were politically motivated and generally led to a less complete and accurate description.
There are situations, in which the needs cannot be anticipated enough for the observer to formulate the right questions in advance. In such cases a very open ended [contextual] observation of the work in progress is proably the only approach that can work. In any case, seeing the 'action in progress' will almost certainly contribute something to understanding which could not be gained from an interview apart from viewing the action in progress.
--
JeromeWillis - 06 Nov 2008
Sybelle's Comments
The basic structure of interviews in chapter 7 is that they are a very informative data gathering method. One on one communication with the user allows the designer to get a good idea of user needs as well as an accurate understanding. There is less chance of mis-interpretation of results from another data gathering method like questionnaires. Interviews are generally open ended questions and hence more data can be collected. The only disadvantage with interviews is that they are time consuming and hence usually only key users are interviewed. It also gets the user involved at the beginning of the designing process. And it is very important to let the user know that he is involved in the process.
In comparison, contextual interviews are stronger at data gathering. They combine 3 features that are "observation, discussion and reconstruction of past events" (these features are discussed in the textbook, page 498). Basic interviews mainly use discussion. A good designer might use some observation techniques. But using a combination of these 3 features, the contextual interview can gather more accurate and in-depth information from the user. There are many aspects of the user's needs that are noticed by observation and may not be specified in words. I think the most effective feature the last one.. review of past events. Sometimes, even the user might not be able to list all their needs at a specific time. Or for that matter, even know what their needs are. But by reflecting on past events, the user as well as the designer can observe a large number of situations that occurred over time and hence deduce the list of user needs. --
SybelleMonteiro
Gurbir Riar
WHAT CAN YOU LEARN FROM CONTEXTUAL INTERVIEW:
Seeing the user's environment can be very useful. By going to the user, you see the user's environment and the actual technology the user works with.
You can answer questions like these:
What is the social environment like?
Are there people around to help the user?
What is the physical environment like?
Is the user on broadband or on a modem?
Does being online tie up a phone line so the user wants to be on and off the Web quickly?
SameerVerma?
Contextual interviews are natural and realistic. They are also usually quite informal.
In a contextual interview, you watch and listen as the user does his or her own work. You don't usually impose tasks or scenarios on the user. The observer listens to the user but may also ask clarifying questions and probe to gain greater understanding of what the user is doing and thinking.In a usability test, you usually have all users do the same scenarios, which gives you comparative data from several people trying the same thing.During a contextual interview, take scenarios along and combine watching users do their own work in their environments with asking them to try a few of your tasks. During a usability test, interview users to find out the sorts of questions, issues, tasks they would do with the site. Let the users do their own tasks. Also have the users do some of your tasks to get data on tasks from all the users.
Nate Delgado 10.2
Contextual inquiry interviews are used to get detailed information and not abstract information. The
important part is to listen and trust the person being interviewed, since they understand their
perspective better than anyone. rely on them to answer your questions, instead of assuming you
understand what they mean. The idea here is specifics. Extract specific aspects of what is being
studied and steer person away from generalizing, but have them describe how they view the issue, or
how they would solve a particular problem.
Contextual Interview by Jatin Aneja
What Can You learn from the Contextual Interview.
Something very important that you learn from a contextual interview is that you get the detailed information about the topic of discussion and not not abstract information. The Aim for the Contextual interview is to get as much data as possible for analyzing future reports. Apart fro Learning from these interviews, there are a lot things that you get benefit for, The first Benefit is that the interviewee are interviewed in their own context and not any other context. Second when The people who are being interviewed are given a task to finish, there is no interference whatsoever from the interviewee. Another aim for this process is to collect all the data and consider it only as a Raw Data and not fully furnished ready to go Data.