From Expert Interview to Technical Explainer

The transcript of a good expert interview is full of the right things in the wrong order. The expert starts with the exception that bothers them most, jumps to a field failure from years ago, defines a term twenty minutes after first using it, and mentions the most important principle in passing. Getting from expert interview to technical explainer is mostly a job of reordering and choosing: what the reader needs first, what can wait, what must be shown rather than told. This Studio Note describes how we do it at AlphaCrew Studio.

Key Takeaways

• We fix the reader and their question before the interview, so the interview and the explainer have the same target.
• The transcript becomes a claims list before it becomes prose. Each claim is checked later by the expert, and claims that came from memory rather than a document are flagged.
• The explanation is rebuilt in the reader’s order: terms and components first, then the mechanism, then a worked example, then limits and exceptions. Research on multimedia learning supports teaching key terms before the process.
• Each part of the explanation gets the format it needs: prose for reasoning, a labelled diagram for structure, animation for change over time, an interactive for exploring a relationship.
• The expert reviews the outline and the claims, not just the finished draft, because that’s where errors are cheapest to fix.

Why transcripts don’t make explainers

Experts organize knowledge around experience: memorable cases, exceptions, the things that went wrong. That’s what makes their knowledge valuable, and it’s also why it can’t be transcribed directly into an explanation. Nisbett and Wilson’s classic review (Psychological Review, 1977) showed that people are often poor at reporting the reasoning behind their own judgments, and Hinds’s 1999 study (Journal of Experimental Psychology: Applied) found that experts were worse than intermediates at predicting what novices would find hard. The expert supplies what’s true; the explainer has to supply the path a newcomer can follow.

How we do it

1. Fix the reader question before the interview

During Discovery we agree who the explainer is for and what they should be able to do or understand afterwards. “A maintenance engineer should understand why a bearing fault shows up at a specific frequency, and what to look for in a spectrum” is a target. “Explain vibration analysis” isn’t. The interview is prepared against that sentence.

2. Interview around cases

We ask the expert about specific situations rather than general rules, and go through each case more than once: the story, then the timeline, then the decision points and what they noticed at each. This follows the logic of the critical decision method described by Klein, Calderwood and MacGregor (IEEE Transactions on Systems, Man, and Cybernetics, 1989). We also ask directly what newcomers get wrong. Our guide to interviewing subject matter experts covers the questions in detail.

3. Turn the transcript into a claims list

Before writing anything, we extract every factual claim from the transcript into a list: each number, each causal statement, each “always” and “never.” Each claim is tagged with its source, either a document the expert pointed to or the expert’s own experience. Claims from memory are flagged for checking. Hoffman, Shadbolt, Burton and Klein’s methodological review of knowledge elicitation (Organizational Behavior and Human Decision Processes, 1995) is a reminder that what comes out of an interview depends on the method, so we treat the transcript as raw material, not as the answer.

4. Rebuild the explanation in the reader’s order

We put the claims into an order a newcomer can follow:

• Terms and components first. Name each part and what it does before showing the system working. Mayer and Moreno’s review of ways to reduce cognitive load (Educational Psychologist, 2003) includes pre-training: teaching the names and characteristics of the parts before the process.
• The mechanism. How the parts interact to produce the behavior, step by step.
• A worked example. One concrete case, often adapted from the expert’s own stories, with the numbers shown.
• Limits and exceptions. The cases the expert talked about first, now placed where the reader can understand them.

5. Choose the format for each part

For each section we ask what the reader has to grasp. Reasoning and trade-offs go in prose. Structure, such as a signal path or the parts of a machine, goes in a labelled diagram. Anything that’s about change over time, such as a wave travelling or a fault developing, is a candidate for animation. A relationship the reader should explore, such as how a parameter affects a result, can become a small interactive. Anything illustrative is labelled as illustrative.

6. Send the outline and claims back first

The expert reviews the outline and the claims list before we write full prose or produce visuals. It’s quicker for them than reviewing a long draft, and it catches order and emphasis problems early. Then they review the draft and any storyboard, and finally the finished piece. The client’s designated experts review technical claims before delivery; in medical-education work, such as our radiology-physics animations for Sybil Digital Learning, the educators provide the subject-matter expertise and the review.

7. Keep the trail

We keep the transcript, the claims list with sources and the expert’s corrections with the finished explainer. When the product or the source material changes, that trail shows which parts need another look.

Where each part of an interview ends up

In the interview	In the explainer	Format
Terms used without definition	Defined first, with what each part does	Prose and labelled diagram
The principle mentioned in passing	The core mechanism section	Prose, diagram or animation
A memorable field story	A worked example, with numbers checked	Prose with a figure
The exception the expert started with	Limits and exceptions, near the end	Prose
“What newcomers get wrong”	Common mistakes, placed where they occur	Callouts
Numbers from memory	Checked against documents or removed	Table with sources

How to put it to work

If you have an hour

Take a transcript you already have and extract a claims list from one section. Tag each claim with its source and flag the ones that came from memory.

If you have a sprint

Rebuild one explainer outline in the reader’s order (terms, mechanism, worked example, limits) and send the outline and claims, rather than a draft, to the expert for review.

If you want it to last the product’s lifetime

Keep transcripts, claims lists and expert corrections with every explainer, so updates start from checked material rather than from scratch.

The question to ask yourself: “Is this in the order the expert remembered it, or the order the reader can learn it?”

Frequently asked questions

How do you turn an expert interview into an article?

Fix the reader question first, extract a claims list from the transcript, reorder the material from the reader’s starting point (terms, mechanism, example, limits), choose a format for each part and have the expert review the outline and claims before the full draft.

Why not just edit the transcript?

Because transcripts follow the expert’s memory, not the reader’s learning path. Terms appear before they’re defined, exceptions before the rule, and important principles in passing.

What should the expert review?

The outline and the claims list first, then the draft and any storyboard, then the finished piece. Reviewing claims is faster and catches errors earlier than reviewing long prose.

When should an explainer use animation?

When the concept involves change over time, such as a wave travelling or a process unfolding. Structure is usually clearer as a labelled diagram, and reasoning as prose.

How do you handle numbers the expert quoted from memory?

Flag them in the claims list and check each against a document or measurement. If it can’t be sourced, it’s removed or stated as an expert’s estimate with that label.

Related reading: interviewing subject matter experts, how we review technical animations for accuracy and multimedia learning principles for technical training.

Sources

1. Nisbett, R. E., & Wilson, T. D. (1977). Telling more than we can know: Verbal reports on mental processes. Psychological Review, 84(3), 231–259. https://doi.org/10.1037/0033-295X.84.3.231
2. Hinds, P. J. (1999). The curse of expertise: The effects of expertise and debiasing methods on prediction of novice performance. Journal of Experimental Psychology: Applied, 5(2), 205–221. https://doi.org/10.1037/1076-898X.5.2.205
3. Klein, G. A., Calderwood, R., & MacGregor, D. (1989). Critical decision method for eliciting knowledge. IEEE Transactions on Systems, Man, and Cybernetics, 19(3), 462–472. https://doi.org/10.1109/21.31053
4. Hoffman, R. R., Shadbolt, N. R., Burton, A. M., & Klein, G. (1995). Eliciting knowledge from experts: A methodological analysis. Organizational Behavior and Human Decision Processes, 62(2), 129–158. https://doi.org/10.1006/obhd.1995.1039
5. Mayer, R. E., & Moreno, R. (2003). Nine ways to reduce cognitive load in multimedia learning. Educational Psychologist, 38(1), 43–52. https://doi.org/10.1207/S15326985EP3801_6