Technical Writing
How to Run (Structured) Interviews
It’s not the questions you ask that matters, it’s the way you ask them. Technical writers, business analysts, and developers all ask questions.
They want answers.
And some are better than others. Some ask many times to get the definitive answers. Others think they have the answer but, on closer inspection, have overlooked some vital point. So, how do you ask the right questions?
Structured Interviews & Task Analysis
When working on business transformation and outsourcing projects, I’d spend endless hours interviewing people.
The more I did it, the more mistakes I saw in my interviewing techniques.
I wasn’t getting the answers I wanted. I was losing time and getting bogged down with thorny SMEs. My manager suggested I look at Structured Interview techniques.
- Structured Interviews are a quantitative research method commonly employed in survey research. It helps ensure that each interview is presented with exactly the same questions in the same order. We used it for Process Design work and developing Action Plans.
- Answers can be reliably aggregated and comparisons made with confidence between sample subgroups or between different survey periods.
- Structured interviews allow you to collect data for a statistical survey, for example, data can be collected by an interviewer rather than through a self-administered questionnaire.
- Standardizes the order in which questions are asked of survey respondents, so the questions are always answered within the same context.
- Minimizes the impact of context effects, where the answers given to a survey question can depend on the nature of preceding questions.
- Used as a qualitative research methodology. These types of interviews suit focus group studies in which it helps to compare/contrast participant responses in order to answer a research question.
- For structured qualitative interviews, interviewers develop an interview schedule which lists the wording and sequencing of questions.
Later, I organized workshops on Structured Interviews where we showed Business Analysts how to interview SMEs and glean the information they needed.
How To Ask Questions for Technical Documentation
Tom Johnson also discusses how to ask questions, for example, to define the topics for an application, ‘Regardless of how many topics you decide to include in your help, asking questions is a tool that can serve you well in all areas of life.’ http://www.idratherbewriting.com/2010/02/17/the-art-of-asking-questions/
How To Ask Questions
Some things to consider are:
- When to ask Open v Closed questions, i.e. which is the most appropriate.
- How to interview groups, i.e. how to ensure that quieter types get heard and not bullied/intimidated at workshops and
- How to verify what the person said is what they actually meant to say..
The final one is much more difficult than you’d think.
How do you interview people?
What mistakes do technical writers make when interviewing? Do they ask too many questions? Or assume they have the information? How do you cope with difficult people at interviews?
I think I speak for many technical writers who work for small software companies when I say that it would be a luxury to interview customers at length, no less have the time and budget to gather in-depth information about their business tasks… But when I can, I find I use the tried and true Five W's and H – see
http://datacapblog.com/?p=194
Five W's and H
Hi Claudia,
Yes, I use that approach as well. it’s simple and effective.
It is odd that technical writers are expected to write documents without access to SMEs, but I guess Developers have the same issue sometimes as they are expected to write code without (sometimes) having access to the requirements. Says something about how IT works…
I have a question for you.
How do you take notes during these interviews?
One of the problems for me is trying to record what is said in a sensible way. I.e. so I can go back and refer to the notes to get the information.
Sometimes when I look at what I write down… I have no idea what it means.
How do you avoid this?
Hi,
Yes, it is odd, and I have never understood why the “bosses” don't understand there is a real return on investing in getting to know the customer… And to answer your question: Beyond having done it for 30+ years, I think the key (for me) is understanding the business context before I start the interview, ensuring the interview stays within that context, and ensuring I ask all the questions I want to ask. Then, all the notes I take HAVE to have something to do with that context/those questions. Since I've documented all kinds of software for both large/small companies and for different audiences, I usually have some understanding of the business process(es) that the software supports, and can be prepared with my list of questions.
hope this helps,
Claudia
<never understood why the “bosses” don't understand there is a real return on investing in getting to know the customer
It’s too far down their list of priorities. Technical docs are not that high on their agenda and/or the budget gets invested elsewhere.
< the key (for me) is understanding the business context before I start the interview, ensuring the interview stays within that context, and ensuring I ask all the questions I want to ask. Then, all the notes I take HAVE to have something to do with that context/those questions.
That makes sense.
Being prepared is half the work, isn’t it?
Keeping the interview within context can be tricky when dealing with ‘strong’ personalities or conf calls where the line drops all the time.
Lately, I’ve asked the SMEs (when possible) to sketch diagrams using flipcharts and whiteboards. This really helps dig deeper, especially if the interview goes on more than 30 minutes and you're saturated with new data.
In the context of structured interviews where you (or multiple interviewers) will be working from a prepared set of questions, I'd put the questions into a checklist (that can be filled in online or on paper) with checkboxes for yes/no answers, and lines for notes for any additional info or explanations given for every question. This allows the interviewers to capture the information as simply as possible in a standard format, which then makes it much easier to count and aggregate the answers into a spreadsheet or other summary document for review and discussion.
I also agree that developers and other SMEs that are difficult to interview are also much freer in describing a highly technical operation if you have them draw you a picture and explain it. I will also copy the sketch for a graphic or flowchart in the docs if possible.
Developers and other SMEs that are difficult to interview are also much freer in describing a highly technical operation if you have them draw you a picture and explain it. I will also copy the sketch for a graphic or flowchart in the docs if possible.
I’ve started to do this more and it really works. I also find that it brings people into the conversation that may have been marginalized, for example, in workshops where dominant personalities take too much space.
<In the context of structured interviews where you (or multiple interviewers) will be working from a prepared set of questions, I'd put the questions into a checklist
Using the checklists helps me to avoid any bias/favoritisms creeping into my documents. Even with the best intentions, we can skew or misinterpret information. The checklists are one way for me to avoid this.