The contextual inquiry is a specific type of interview for gathering field data from users. It is usually done by one interviewer speaking to one interviewee (person being interviewed) at a time. The aim is to gather as much data as possible from the interviews for later analysis.
Important benefits of this type of interview are:
- Interviewees are interviewed in their context, when doing their tasks, with as little interference from the interviewer as possible.
- Data should be gathered during interviews with little or no analysis, interview should result in raw data.
Planning a contextual inquiry means to make sure that you can interview with the right users and that they are not entirely negative being interviewed with. In traditional interviews it is sometimes difficult to get interviewees to interview with, because they claim that they do not have got the time. In contextual inquiry it is actually much easier, because the main part of the interview actually consists of watching users do their work and interacting with colleagues, which doesn't steal much time from the users.
When at the interview with the interviewee it is very important to have a focus, a focus can be seen as a number of assumptions and beliefs concerning what we want to accomplish and how we want to accomplish it (short example: "We're building a system to handle customer inquiries. It is a straight-forward process. Should manage 100 customer inquiries a day"). Building up this focus can be done in conjunction with the person ordering the contextual inquiry. Another way of building a focus is for example by focus groups or user surveys. Important when it comes to focus is to realise that a focus is never, ever true. It truly is not complete and represents (ideally) only part of the truth. For successful interview results, the focus must be severely challenged by the interviewer.
There are typically four phases in the interview:
- Traditional interview, which is the phase where the interviewer gets an overview of the users work and start to establish trust (by promising confidentiality, tell them reason for interview) with the user. Also start recording during this phase, if customers are part of the users interaction, make sure that you get their consent or if that is not possible, do not record. If the situation is such that the interview cannot be recorded, it can be beneficial to be two interviewers.
- The 'switch', from a traditional interview to a master-apprentice relation. It is important to tell the users that we want to learn from them by watching and occasionally interrupting. Make sure that you have agreed with them when you can interrupt. It is important to be able to ask users about things happening, but at the same time not disturbing their work, for example during interaction with customers.
- Observation. The users are the master and they 'run the show'. The interviewer (apprentice) should only be there watching and occasionally interrupt (when feasible) to ask questions about things that occurred. Do not hesitate to ask any questions that may or may not be of relevance. When at the interview it is impossible to know what is relevant or not relevant, so note down as much as possible. When observing the users, remember your focus and probe them depending on the focus.
- Summarisation. In this phase the interviewer should summarise what they have learnt during interviews. Be attentive to users reaction to your summary, because you do not want to get it wrong (they do not always tell you that you are wrong, so you have to figure it out by yourself). If you didn't get it right, ask them questions and build the story together with them.
Reporting and analysis of data takes place next. See below for reference.
Since this method produces vast amounts of data it is important to analyse the data. This can be done using the contextual design method or any other method that may be handy. Examples of method that may be useful is task analysis to verify the process. The most useful method to analyse the amount of data may be to create an affinity diagram.
Beyer, H. & Holtzblatt, K. (1998) Contextual Design: Defining Customer-Centered Systems. San Francisco: Morgan Kaufmann Publishers ISBN 1-55860-411-1©UsabilityNet 2006. Reproduction permitted provided the source is acknowledged.