Re: Research interviewing tips

["Wing, Michael J" <mjwing -at- INGR -dot- COM>]

> BEFORE THE INTERVIEW:
>
> -  How do you identify subject matter experts?  Through management,
> organizational charts, or
>    through interviewing workers themselves?
>
We have an infranet.  Most of the time I can get names from a
spreadsheet for each functional area of the product.  If the spreadsheet
is not up to date or incomplete, I'll look at who the author is in any
specification, white papers, or other documents.  Failing that, if I
know the department number, I'll go to the on-line corporate phonebook,
retrieve a list of department members and phone numbers.  I'll then call
someone on the list and see if they will 'rat out' the responsible
party.

> -  Who do you interview most often -- engineers, programmers,
> management, sales/marketing,
>    etc.?
>
I deal mostly with programmers, product planners, testers, and customer
service people.  I limit interaction with Marketing to only what is
absolutely necessary;^).  I don't want to turn my documents into on-line
advertisements, links to Marketing sites, and I especially don't want
them infesting my documents with overworked, trite-by-pumped-up phrases
(such as 'state-of-the-art', 'leading edge', and so forth).

> -  Do you usually know your interviewee prior to the interview?
>
About half the time.  However, as the project progresses, I am making
less introductions.

> -  Why (specifically) do you conduct most interviews?  (Ex:  to gather
> product information for a
>    user manual.)
>
I research the matter as much as practical before talking to them.  I
even write fiction to fill in the blanks.  That is because Engineers do
much better at correcting what is wrong than staring at a blank notepad
and being told to list everything there is to know.  Believe me, they
hate the blank page.  They also will forget half of what they need to
tell you.  Also, in my experience, they hate the 'fill in the
Writer-prepared template'.  Every rookie writer comes up with this
approach.  Many Engineers hate to fill in prepared templates.  It's like
homework.

Instead of the journalist or interviewer approach, I use a lawyer-like
approach.  I script my questions focusing on some specific questions.  I
compare the answers to what I thought they might be.  I plan on only
talking to them for 10 to 15 minutes.  I tell them this when I ask to
speak with them.  However, I goad them into extending the interview
through some other techniques.

One technique is the Trojan horse.  In this approach I come with one or
two questions that are easy to answer.  However, I slip in 10 or more
"what if" situations and get them elaborating on how they have foreseen
this and that and how the product handles it.  Because I document
automation programming code used in customizing our products, I hit them
where they live.  If I approach them with a piece of my code that
doesn't work, they'll drop everything they are doing to see why.  As
they test my code, I ask them everything about every method, argument,
property, and maybe even ancestry.

Another technique is the wrong conclusion.  I ask the Engineer to
confirm my understanding of the product (or function thereof).  As I
start spouting fiction they can't resist correcting me (It's like
resisting the shave-and-a-haircut knuckle rap).  And they do reply, "
WRONG!  NOPE!  You're way off!"  If you have thick enough skin to stick
around and hear the answers, they will tell you in no uncertain terms
what is right and wrong.

> -  Do the experts readily agree to taking time for an interview?  What
> do you do if they're
>    reluctant?
>
I don't tell them it's an interview.  I usually drop by their office.
If they are busy, I ask when I can come back.  If I don't get a
response, I start playing with their gadgets picking things up on their
desk, reading their magazines, and so forth.  Well, not always, but I
will hover until I am rescheduled or they work with me then.

> -  What kind of research do you do before an interview?  How much?  Do
> you research the
>     interviewee before going in?
>
I do as much research as practical.  I read whatever specifications,
white papers, example code, technotes, and so forth that are available
on the infranet.  I will also try to write a small program within the
area of automation for which they are responsible.  As I hit stumbling
blocks, I script my questions focusing on the exact problem(s).  When I
can't progress further or my internal timer says that I will waste too
much time, I talk with the Engineers.  I now have my focus, questions,
Trojan horse (non-working example code), and wrong conclusions (the
answers I made up to explain the stumbling block problems).

> -  Do you prepare a set of written questions before the interview?
> How else do you prepare?
>
Most of the time.

> DURING THE INTERVIEW:
>
> -  Do you interview in person, in writing, on the phone, or by
> videoconference?
>
In person.  If it's quick, I do it by phone.

> -  Do you try to interview one expert at a time, or conduct a group
> session?
>
For specific questions, it is usually one person.  However, for document
scope, design, scheduling, implementation, and so forth it is a group
(usually product-area leads).

> -  How long do you schedule for the meeting?
>
For individuals, only 10-15 minutes.  For groups, 1/2 to 1 hour.

> -  Where do you interview?  In a noisy cubicle, in a conference room,
> at lunch?
>
Actually, half my conversations start at the coffee machine, hallway,
and so forth and move to an office.   Scheduled group interviews are in
a meeting room or large office.

> -  How do you take notes?  Do you use shorthand or a personal form of
> shorthand?
>    Do you use a tape recorder?  Do you share your notes with the
> interviewee to clarify comments?
>    Do both of you draw on a board?
>
For one-on-one interviews, I mark up my printouts, notebook, scrap
paper, printed e-mails, or even a discarded candy bar wrapper.  Usually,
the Developer, sensing that I may be asking them to write something,
will make me privy to a private development infranet site, notes,
half-finished white paper, and so on.

For group meetings, I mostly use a notebook.

> -  Do you open the interview with friendly chat, or get right to the
> point?
>
I usually get right to the point and then lighten up.  This reinforces
the idea that it will only take 10 to 15 minutes.

> -  What types of questions are effective? (open-ended, closed or
> narrow question, yes-no, etc.)
>
Actually, the "Please verify that I understand this" statement followed
by a mixture of fact and fiction is effective.  Also effective is the
"It doesn't work.  I just don't know if it's my logic or a bug in the
program" type statement.

> -  What types of listening responses are effective?  Do you maintain
> an awareness of body
>    language?
>
Certain body language I don't want to acknowledge?  Especially, if I
forced the interview by touching their toys, magazines and gadgets.
Usually, I try to end the interview (when I have enough to go on or I
feel that I got them at a crunch time) before they do.  That way, they
don't feel that they had to get rid of me and thus, are more responsive
next time I drop by.  If I still need more info, I'll ask them to sic me
on someone else.  Sometimes, they will even escort me to that person.

> -  What do you do if you just can't understand what the expert is
> talking about?
>
I repeat what they have told me in my own words.  I then let them put on
my brakes and set me on track.  If that doesn't work, I put focus back
on user instructions.  Such as, "Is this something that the operator
needs to know to do this function?".  "If not, what do they need?"

> -  What do you do if the interviewee keeps getting off track?
>
A "slap back of the head" usually is effective ;^)  Actually, I remind
them that I only planned to take 10 - 15 minutes of their time.
However, if they want to give more, I'm all ears.


> AFTER THE INTERVIEW:
>
> -  Do you organize your notes/transcribe immediately, or wait a while,
> or leave your notes as
>     they are?
>
I usually replace the fiction in my document with fact.  Most of my
notes are comments in a word processing or other on-line document.  I
usually color-code the fiction and points-to-cover.  I then rewrite
these sections and remove them from the on-line document.  When all the
color-coded sections are answered, rewritten or removed, the section is
ready for review.


> Thanks again,
>
> Julie Brown
>
>
Michael Wing (mailto:mjwing -at- ingr -dot- com)
Principal Technical Writer
Intergraph Corporation; Huntsville, Alabama
http://www.ingr.com/iss/products/mapping/
(205) 730-7250

"So also the tongue is a small part of the body; and yet it boasts of
great things.  Behold, how great a forest is set aflame by such a small
fire!"

-- James 3:5


>


	http://www.documentation.com/, or http://www.dejanews.com/