This page contains guidelines for conducting user interviews and a Discussion Guide which outlines topics of interest that we would like to cover in the interviews. The Discussion Guide should be used as an informal list of topics we would like to cover in interviews. The guidelines below are paraphrased from planning documents of user studies we conducted at HP Labs and later labs at Agilent Labs. As guidelines, they are meant to provide an outline of some basic principles and techniques we found useful, not a formal set of rules to be followed.

Suggested Guidelines for Interviewing

We found it most productive to interview in teams, or at least in pairs. In teams, one person can be responsible for note-taking while the other(s) can devote their full attention to the conversation. Another advantage of team interviewing is that the sharing of reactions in debriefing can help synthesize conclusions and new ideas.

Before each interview, we found it a good idea to review among ourselves what the goals of the interview are and recall what questions or issues we especially wanted to cover in the particular meeting. The topics in the Discussion Guide can serve as an ongoing list of these important issues. They are best used as aids for moving the conversation along, rather than as a questionaire. It should not be essential to cover all questions in the guidelines in all interviews; rather it is more productive to let the interview take its course and to capture the information in the users' own words. Interviews should be informal and open-ended. We will have specific ideas in mind of what we want to cover, but it is essential to allow these conversations to unfold in their own way, rather than presenting a laundry list of questions. In fact, it is a good idea to put aside any papers with written questions or topics before the interview starts (after reviewing them), since that will help us listen more closely to the cues of the people we are talking to. We need to follow those cues if we want to understand what ís important to the people we interview.

We found it helpful to listen especially carefully to the language people use, and to try to adopt their terminology in interviews and other conversations whenever we can. Noticing the differences between the terminology of people we interview and the terminology of our own group of developers (or what we understand to be conventional bioinformatics language) can be a fruitful source of insight about the way users go about doing things.

We found it useful to debrief among ourselves right after the interview. In the debrief, we can call attention to any interesting things that surfaced, see if any questions have arisen for follow-up interviews or observations, and discuss the logistics of the interview to see if anything should be changed for next time.

Some user research practitioners tape all interviews. We did this at HP Labs for several years, but eventually abandoned the practice in favor of concentrating on taking good notes and writing them up as soon as possible after the interviews. We found that this was just as effective as taping and transcribing interviews, while being lower overhead and avoiding the problems of people feeling self-conscious when being taped.

It's essential to take good notes during an interview and, even more important, to write up these notes as soon as reasonable after the interview, while the conversation is still fresh in our minds. Such 'field notes' are very useful for setting the scene, summarizing the important features of a conversation, providing some material for reflection, and pointing to next steps.

Discussion Guide

DiscussionGuide (last edited 2009-02-12 01:03:34 by localhost)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux