How to Conduct a Contextual Inquiry

Let's do this as a list of steps:

1 Someone take the lead

Somebody on the IT team should take the lead in learning about contextual inquiry (perhaps reading this article and others which are available on the web), and then train the rest of the team on the method. Some proponents of the method think that you need a half-day workshop (or more), but I think you can get the basic ideas across in a couple of hours. That seems to have worked for me, anyway.

3 Arrange to have your development team meet with members of the user team

The inquiry should last between two and three hours, depending on the complexity of the user's job. (If you find that your inquiries are falling way outside these bounds, you might want to adjust your focus appropriately.) IMPORTANT: The inquiry takes place at the user's workplace (office, cube, whatever), because you are trying to understand the user's work by observing the work itself, rather than by hearing a description of the work. So remember to ask the user where his or her workplace is.

4 On the number of analysts

Normally inquiries are done 1-on-1, but I've had good results with 2-on-1 inquiries as well (i.e., two IT analysts interviewing one user), as long as the analysts are careful to put the user in the driver's seat and avoid intimidating the user. (2-on-1 inquiries allow the IT team to have access to more users, which helps them to see patterns of similarity and difference. They also allow for multiple perspectives on a single user.) If you interview a large number of users, don't do everybody all at once. I would recommend your team interviewing three or four users one day, skipping a day or two (this will allow you to do work models for your three or four users the day immediately following the inquiry), and doing another three or four users, etc., until you've interviewed all of your users. (I am saying that the team as a whole interviews a total of three or four people; any given person interviews only one person per day to avoid getting the users all jumbled up.) Also, let common sense prevail if you have two analysts per team. For example, if some members of your team are less proficient in verbal English, pair them up with members who are more proficient. If some of the people on your team have prior experience with contextual inquiry, pair them up with people who don't have that experience.

5 Tape recorders

Make sure that there is one tape recorder for each inquiry. Audio tape recorders are good enough.

6 Arriving at the inquiry

When it's time to do the actual inquiry, it goes without saying that you will want to be on time, since this is really the user's first impression of the development team, and a lot hinges on the relationship that the development team can establish with the user team. Bring the tape recorder, and importantly, bring paper and a pen to take notes. Even though everything is on tape, you'll want to take notes because (1) if you don't get the tapes transcribed, you won't want to have to search for important points on audio tape; (2) if you do get the tapes transcribed, it will still take a while, and you'll want to build work models right away while the inquiries are fresh in your mind; (3) taking notes while the user is speaking signals your interest in what she has to say, and that will help establish the right kind of mentor-apprentice relationship that you need for a successful contextual inquiry.

7 Setup

Ask the user if you can record the session, and assure him or her that in any event, the data you collect will be confidential in the sense that only members of the IT development team will know which user said what. If the user doesn't want you to record the session, no biggie—just take notes. You can still do the inquiry.

8 Give an overview

Take a few minutes to explain to the user the development team to und establish a rapport with the user. Humor he it. (Not me, but maybe you.)

9 What to do for two hours

For the most part, just ask the user to show you what she (I'll assume she) does as part of her normal job, and ask lots of questions when something isn't clear. The user knows that you don't know anything about her job, and will generally fall over backwards to answer your questions. The official approach seems to be to ask the user really just to go about her job as she normally would. I agree with that in general, but there are a c can see this not being the best approach:

• There is some important task that is performed periodically, and today isn't the day it would normally be performed. The user still wants to show you how to do the task. By all means let her.
• This one's controversial, but I stand by it. You may have a user who is especially insightful about the nature of the job, for whatever reason. If you notice after a few minutes that she easily separates what's essential about the process from what's just conventional (perhaps due to the nature of the existing software system, or whatever), it can be ex of questions about how the process works, what the various roles are, how the roles interact, what influences the various roles have over each other, etc. This suggestion is probably controversial, and probably just got me booted out of the "good contextual inquiry practicioner" club, because it violates the principle of context (i.e., understand the user's job by watching her perform the job in context) that is key to the contextual inquiry method. But I offer the suggestion in spite of that just because insightful users of this sort can provide a very helpful view of the forest where most of the inquiries will provide helpful, detailed views of trees.

10 Collect work artifacts

Try to collect lots of "work artifacts" over the course of the inquiry. Ask the user to forward e-mails, spreadsheets, lists, whatever it is that the user uses to do her job.

11 Look for work breakdowns

Pay attention for instances where the user indicates that something doesn't work very well with the existing business process, line of communication, software, etc. These are called work breakdowns, and they represent opportunities where the IT team might be able to do something helpful.

12 Maintain focus

If the inquiry strays from the focus, try to bring it back. Follow up on some previous point related to the focus. If you are paying attention (and you have to be, if you are taking good notes), then this should be easy to do.

13 Apprentice model

In general, try to act like an apprentice. Despite the fact that I've given a list of steps here, the actual inquiry itself should be organic, not a rigid collection of steps. As long as you act like somebody who is trying to learn what the user's job entails—and that's exactly what you are, so it shouldn't be hard—you can't go wrong.

14 Bye

When you're done, thank the user and ask her if it will be OK for you to contact her with follow up questions, ideas, etc. Remind the user that your team intends to treat the users as full partners in the development of the upcoming software system, and so you will need to contact her and even meet with her from time to time, if that's OK. Don't forget your tape recorder or your brown leather jacket.

15 Transcriptions

If you have the bucks for it, pay a transcription service to transcribe your tapes. It's generally cheaper if your interviews are 1-on-1, if you use standard cassette tapes, and if there isn't a lot of background noise.

Post a comment