Chapter 10: Interviewing

1
Chapter 10Interviewing
2
Objectives

• To describe the interviewing process
• To provide a generic template for conducting user
  and stakeholder interviews

3
Interviewing

• One of the most important and most
  straightforward requirements gathering techniques
  is the user interview
• A simple and direct technique that can be used in
  virtually every situation.
• However, the interviewing process is not easy,
  and it forces us to get "up close and personal"
  to the "User and the Developer" syndrome.

4
Context-Free Questions

• A context-free question helps us gain an
  understanding of the real problem without biasing
  the user's input. These questions dont imply any
  particular context.
• Asking questions about the nature of the user's
  problem without context for a potential solution.
  Example
• Who is the user?
• Who is the customer?
• Are their needs different?
• Where else can a solution to this problem be
  found?
• What problem does this product solve?
• What problems might this product create?
• What environment is the product likely to
  encounter?

5
Context-Free Questions(Cont.)

• These questions force us to listen before
  attempting to invent or describe a potential
  solution.
• Listening gives us a better understanding of the
  customer's problem and any problems behind the
  problem.
• Context-free questions generate a deeper
  understanding of the product and project.
• Meta questions questions about the questionsare
  a special sort of context-free question. Meta
  questions, such as Do my questions seem
  relevant? or Is there anything else I should be
  asking? are likely to surface areas where the
  customer assumes that you already know.

6
Solutions-Context Questions

• After we ask the context-free questions, we can
  explore the suggested solutions.
• Solution-context questions

7
Open-ended Questions

• Open-ended questions invite the customer to
  expand on the topic.
• Use What questions to learn about events and
  considerations.
• What happens next?
• What factors are involved? 
• How questions ask about the way things happen.
• How do you use the product to__________?
• How do people decide which option to select?
• Could questions ask the customer to imagine or
  express a wish.
• Could you conceive of an example when youd use
  the product this way?
• Could you see a way to use the product to solve
  this problem?

8
Closed Questions

• A closed question is one that naturally leads to
  a one-word answer, usually Yes or No.
• Questions that start with Can, Do, Are, or Is are
  usually closed questions. 
• Q Do you have any problems with the wonder
  widget?  
• A No.
• Closed questions are useful for confirming
  specific information. You want to delve beneath
  the surface, and closed questions wont help you
  with that. 

9
Past, Present, Future

• Ask questions about past use to understand
  problems and weaknesses in the product or
  feature.
• Past When has the product failed to perform as
  you expected?
• Use present-time questions to learn about how the
  customer currently uses the product or how he
  currently performs his job.
• Present How are you using the product now?
• And ask questions about the future to learn about
  trends and anticipate future needs.
• Future How do you see your workflow changing in
  the next several years?

10
Tell Me More

• Dont stop at the first answer. Follow an
  opened-ended question with a probe to gain
  further insight.
• A good interviewer will elicit a second, third,
  and even a fourth response.
• When you want to learn more, use questions like
  these
• What else?
• Can you show me?
• Can you give me an example?
• How did that happen?
• What happens next?
• Whats behind that?
• Are there any other reasons?

11
Tell Me More (cont.)

• Be sure to probe for more information when you
  hear emotion or judgment
• I hate the way the feature operates!
• The product does a poor job.
• Dig deeper to identify unmet needs or weaknesses
  in the product.
• Vague statements like The product must be easy
  to use call for probing to learn what easy to
  use really means to the customer.

12
Generic Interview Template
13
Generic Interview Template (Contd)
14
Generic Interview Template (Contd)
15
Generic Interview Template (Contd)
16
Generic Interview Template (Contd)
17
Tips for a Successful Interview

• Prepare an appropriate context-free interview,
  and write it down briefly in a notebook for
  reference during the interview. Review the
  questions just prior to the interview.
• Before the interview, research the background of
  the stakeholder and the company to be
  interviewed.
• Don't bore the person being interviewed with
  questions you could have answered in advance. On
  the other hand, it wouldn't hurt to briefly
  verify the answers with the interviewee.
• Write down brief answers (short notes) in your
  notebook during the interview. (Don't attempt to
  capture the data electronically at this time!)
• Refer to the template during the interview to
  make certain that you're asking the right
  questions.

18
INTERVIEWING USERSTIPS

• Prepare to interview users by reading background
  documentation first.
• Generate a written list of questions to help you
  interview.
• Information needed depends on the system, but
  some information to find out from users might
  include
• What are the user types, their required skills?
• What work do they do what do they authorize?
• What problems and irritations they have doing the
  work?
• What are the work cycles and timing how often
  something is done and how long it takes what is
  the criticality of its timing?
• What is the sequence of work steps or processing?
  
• What is the work product at the conclusion of
  each step?
• Where the work is performed?
• What organizational goals and objectives, legal
  requirements, or other needs does the work
  support?

19
INTERVIEWING USERSTIPS (cont.)

• Watch for areas in the business process that use
  subjective decision-making. You will need to work
  with users or their management to clarify policy
  if this activity will be automated. Delays in
  agreement on the policy often occur and can stall
  your effort.
• Users may present a requirement as a solution.
  Find out why they want this solution by asking
  "what" that solution provides or does. Asking
  "why" makes it sound as if their request must be
  justified to you.
• Users resent being told the information they are
  providing is not needed. If the information is
  relevant to the topic, but too detailed for the
  current discussion, ask if you can return for
  that information later. Be sure to put in your
  notes that additional detail is available and
  from whom so you can come back for it without
  having to ask who has it.

20
INTERVIEWING USERSTIPS (cont.)

• Requesting the same information over and over
  indicates incompetence. Users will complain to
  their management about this.
• If possible, assign one analyst to take notes
  while another interviews.
• Remember, it isn't the users' job to tell you
  what kind of technology they need. If you want to
  know what kind of technical capabilities they
  might like, be prepared to give them examples.
• Try to see the work performed. Get copies of
  forms, outputs, and information used in the work,
  including help sheets and notes posted by the
  users at their desks.
• Identify all parties who will use the
  requirements

21
Compiling the Needs Data

• Your problem analysis will have identified the
  key stakeholders and users you will need to
  interview to gain an understanding of their
  needs.
• Typically, it does not take many interviews to
  get a solid understanding of the larger issues.
• In many cases, after just a few interviews, user
  and stakeholders needs will start to be repeated.
  
• This means that you may be starting to get
  convergence on some common needs.
• This is to be expected, especially among those
  users or stakeholders who share a common
  perspective.

22
A Note on Questionnaires

• There is no substitute for an interview.
• Do it first!
• Do it for every new class of problems!
• Do it for every new project!
• The questionnaires technique is not a substitute
  for interviewing. Reasons
• Relevant questions cannot be decided in advance.
• The assumptions behind the questions bias the
  answers.
• It is difficult to explore new domains ("What you
  really should be asking about is . . ."), and
  there is no interaction to explore domains that
  need to be explored.
• It is difficult to follow up on unclear user
  responses.

23
Key Points

• Interviewing is a simple and direct technique
  that can be used in most circumstances.
• Context-free questions can help achieve bias-free
  interviews.
• It may be appropriate to search for undiscovered
  requirements by exploring solutions.
• Convergence on some common needs will initiate a
  "requirements repository" for use during the
  project.
• A questionnaire is no substitute for an
  interview.