How Technical Writers Gather Information: Interviewing the SMEs
August 25, 2008 by John Hewitt
Subject Matter Experts (SMEs / Smees) are resources who have expertise in the product / subject you are documenting. Many people within a company become SMEs for various reasons. Business analysts, program analysts, engineers and designers are often the people who create the design for a product or request the changes that will be made to a product, so they become SMEs. Programmers write the code that makes a product run, so they become SMEs. Trainers teach people how to use the products, so they become SMEs. Testers make sure the product operates properly, so they become SMEs. Technical support works with people to solve their problems using the product, so they become SMEs. If you spend enough time documenting the same product you may also eventually become a SME.
Most SMEs are technical people, but many of them are not skilled at explaining how things work. That is one of the reasons why technical writers get hired in the first place. Technical writers explain things that other people either haven’t got the skills to explain, or haven’t got the time to explain. That means the technical writer has to talk to these people and get the information out of them. This isn’t always easy, but it is generally necessary.
In many cases, SMEs are very busy. Getting a second meeting with them may be difficult, so prepare as much as possible for the first meeting by getting to know the subject, figuring out what questions to ask and having any necessary materials ready. Here are a few more hints to help you get the most out of a SME.
- Bring an audio recorder. This doesn’t eliminate the need to take notes, but it does give you a backup. Most people speak far faster than most people write, so having the recorder makes it easier to go back and get information.
- Ask questions that get the SME to address your needs as a technical writer. Here are a few starters:
- What does a first time user need to know about this?
- What does an experienced user need to know about this?
- What is the process for completing the task?
- What happens if the user makes a mistake?
- Are there any other parts of the product/documentation that will need to change because of this?
- Be courteous even if the SME is not. An angry SME is a real pain in the neck.
- Bring snacks / bribes.
- Follow up with an email that restates the information that the SME gave you so that they have a chance to make changes and so that they will not be able to claim they were misunderstood.
Does anyone else have any tips to add?
Part Two of a Series:
Part One: How Technical Writers Gather Information: Attending / Holding Meetings
Related links
- A Career in Technical Writing: The beginning of a new series (0.500)
- A Career in Technical Writing: Life as a wannabee (0.500)
- A Career in Technical Writing: Two dates to the prom (0.500)
- A Career in Technical Writing: The fax about outsourcing (0.500)
- A Career in Technical Writing: A strange new world (0.500)





I think this article gives a false impression of how Technical Writers gather information. You failed to mention that some Technical Writers have technical, scientific, or programming backgrounds, and wouldn’t need to interview an SME at all, though they may test their documentation with the programmers, developers, etc.
Elise,
Not true. This post is about gathering information from SMEs. It is a about a single way to get information. It is not about ALL ways to get information. It is part of a series.
I also mentioned that some (far from all) documentation people become SMEs. I have a substantial technical background, but I still interview the SMEs because they are the ones who made the changes to the product or otherwise know the product. They know what they did, and if I assume I know everything just by looking at the product, I am doing the users a disservice. Anyone who thinks they can operate as an island just because they have technical skills is headed for real trouble.
That said, clearly the usability of my series needed improvement so I have linked to the first post in the series.