Making the Complex Simple When Interviewing SMEs

"I have to write the user documentation. Please explain to me how it works."

If you’ve ever said this kind of sentence, you were interviewing a subject matter expert (SME). Typically, the goal is to access their knowledge about a product and transform it into actionable instructions for specific audiences.

Explanations from SMEs usually need simplification, and that task can be arduous. There are too many areas, concepts, and facets to tackle.

Yet, there is only one facet to tame before anything else: assumptions.

Can we avoid assumptions?

Ideally, communication should be free of assumptions. That’s particularly true in technical communication.

Assumptions make explanations concise, and SMEs love to deliver brief knowledge-sharing. At the same time, assumptions hide some information crucial for newbies to a topic, and the audiences of instruction manuals are newbies by definition.

Nevertheless, in the real world, assumptions are unavoidable. The best we can do is to list those assumptions honestly, which is the approach I follow and that I describe below.

Four explicit assumptions

The recipe I propose comes from experience. It’s a collection of observations and actions that I’ve found valuable.

Yet, observations are not truths, so I list them as assumptions.

Let's get started.

Assumption #1: definition of the problem

Users need a simple way to get answers about a product.

The key word is "simple": it focuses on the audience's perception of technical communication. We, as technical writers, only succeed when our target audience gets things done effortlessly, thanks to the knowledge we transfer to them.

How audiences get things done is the problem we have to tackle. Since there is no solution for undefined problems, the starting point is to define those problems clearly, with the simplest possible language.

Assumption #2: definition of intrinsic and induced complexity

Two kinds of complexity arise to understand a subject matter: intrinsic and induced.

Intrinsic complexity comes from the topic. Induced complexity comes from SMEs.

There is no way to melt down the complexity of a topic but to study it. That’s what I call "intrinsic" complexity.

On the other hand, SMEs explain topics from the standpoint of their deep knowledge of the subject matter. In some way, they "are" the subject matter, and their language is far from a newbie perspective. That is what I call "induced" complexity.

Further assumptions #3 and #4 cope with both kinds of complexity but are mainly aimed at taming the induced one.

Assumption #3: definition of the words

The glossary is the communication foundation to build together with SMEs.

Trivial to say, but ambiguity in words' meaning leads to unreliable communication. That's dramatically true in technical communication. So, defining each word is the way to mitigate the induced complexity and melt down the intrinsic one.

Assumption #4: definition of the relationships

Once a formal definition of each word is available in the glossary, relationships between concepts emerge.

For example, the primary relationship is "is a," which states which words convey concepts that are specific cases of more general concepts. Another relationship is "depends on," which states a dependency between concepts. And so on.

When audiences try to get things done with a product, they start a learning path to get the answers they need. Technical writing provides them with this learning path as plainly as possible.

Relationships hook concepts together, facilitating exploration and learning. This approach melts down the topic's complexity into simplicity through words and their concepts.

What about implicit assumptions?

Implicit assumptions are out of control by definition, because they are not said. If I could list the undeclared assumptions, they would be indeed explicit.

Nevertheless, by listing the four assumptions above, I allow you to check them. The list works as a kind of microscope for you, as the reader, to inspect my recipe and detect what otherwise would have remained tacit.

Takeaway: rely on structured communication

What's paramount in technical writing is to reveal to the audience the logical structure behind a complex topic by mirroring that structure in the communication.

SMEs focus on their subject matter, so they structure their communication around the aim of the knowledge they use. Instead, technical writers focus on audiences and structure their communication around sharing knowledge.

The glossary is the point of contact that makes explicit the learning path for audiences by revealing relationships and allowing them to detect and give a name to assumptions. And melting complexity into "simple."