One Expert Interview, Five Pieces of Evidence Worth Publishing

“Can you give us a quote for this article?” is a small request. It can also produce a very small contribution.

An expert gives a sensible answer. The writer adds it to a paragraph. The article now has an expert quote, but the reader may not have learned anything they could not find elsewhere.

I would rather use the conversation to understand a decision the expert makes, the evidence behind it, and the conditions that could change it.

One focused interview can produce several useful pieces of material. They do not have to become five separate articles. Often they belong together in one much better explanation.

Start with a real decision

Before the interview, I would define the reader and the problem. “Tell me about your industry” is too broad. “How do you decide whether this problem needs a repair or a replacement?” gives the conversation somewhere to go.

I would ask the expert to bring a specific example they are allowed to discuss. If it involves a client, private data, or internal material, we would agree what can be used and how it can be described before publication.

This builds on what companies get wrong when they ask experts to write. The job is to uncover the reasoning, not make the expert produce a polished article on demand.

1. A decision rule

The first useful output is a rule with conditions.

I would ask: what do you check first, and what result makes you choose a different action?

In a hypothetical interview with a website migration specialist, “check redirects” would be too general. A more useful explanation would identify which old URLs need a destination, how the destination is chosen, and what happens when there is no equivalent page.

The publishable material might become a decision tree or a short checklist. I would keep the limits beside the rule so an exception does not disappear during editing.

2. A failure case

Next, I would ask about an approach that did not work and what revealed the problem.

What was the original assumption? What did the team observe? What changed after that?

The point is not to force a dramatic story. An ordinary mistake with a clear diagnostic lesson can be useful. For example, a migration test might reveal that a redirect technically works but sends readers to a page that no longer answers their question.

If that is an illustrative scenario rather than something the expert personally observed, I would label it as hypothetical. I would not turn an example into a client case study.

3. A comparison based on criteria

“Which option is best?” often invites an answer that is too broad to help.

I would ask when the expert would choose each option, what they would give up, and which criteria matter most.

For the migration example, the useful comparison might be between retaining a URL, replacing it with an equivalent page, or retiring the content. The output would explain the conditions behind each choice rather than announce one universal winner.

A comparison table works well when the criteria are consistent. If the expert keeps changing the basis of comparison, that is something to clarify before writing.

4. An exception that changes the advice

This is the question I would make time for even in a short interview: when would your usual recommendation be wrong?

The answer often reveals the boundary of the expertise. A process may depend on the size of the website, the availability of historical data, or whether a particular system can support it.

I would also ask how a reader could recognise that exception in their own situation. “It depends” becomes useful when the expert names what it depends on.

This is closely related to why expertise should reduce uncertainty. A qualification should help someone decide, not leave them with a longer list of unexplained variables.

5. A documented process

Finally, I would ask the expert to walk through the task in order.

What information is needed before starting? What is the first check? Where does someone review the work? What counts as completion?

The useful output could be a worksheet, an annotated example, or a process with checkpoints. I would avoid polishing it into a perfectly smooth sequence if the real work includes iteration or unresolved decisions.

A process becomes more credible when the reader can see what evidence would cause the expert to go back and reconsider an earlier step.

Separate testimony from verified evidence

An interview gives us the expert’s account. That account may be valuable, but it is not automatic verification of every factual claim.

I would keep a simple evidence note for each proposed statement: what was said, whether it is opinion or an observation, what supporting record exists, and what we are allowed to publish.

A claim such as “this reduced errors by 40%” needs a defined measure, a comparison period, and supporting data. If those are unavailable, I would narrow or remove the claim rather than invent precision.

Before publication, I would ask the expert to check the reasoning, attribution, and qualifications. Their review should catch changes in meaning, not merely approve the spelling of their name.

What I would do with the five outputs

I would map them to the reader’s questions. The decision rule might open the article, the comparison could explain the options, the failure case could show what to watch for, and the exception could prevent misuse. The process could become a practical takeaway.

If an output deserves its own page because it serves a separate task, that is an editorial decision. Five useful insights do not automatically justify five URLs.

What I would check on Monday

• Choose one reader decision for the interview.
• Prepare questions about rules, failures, comparisons, exceptions, and process.
• Record the source and status of important claims.
• Keep hypothetical examples distinct from observed cases.
• Ask the expert to review meaning and limits before publication.

The result should help the reader think more clearly. The expert’s name matters, but the reasoning is what makes the contribution useful.