The Subject Matter Expert (SME) most likely has a viewpoint of his project and what is important to it that is different, if not at odds with, the viewpoint and needs of the audience for whom you are writing. You need to understand this and know how to work with or around it when gathering information.
Different Viewpoints, Different Approaches
Your SME is building the project. You are, most likely, explaining how to use it. This in and of itself creates a gap in approach. Software developers, for example, often want to delve deeply into the underlying architecture of how and why pushing button A produces result B. Your audience of users probably only cares that A will cause B! (Developers often disparage the user who just wants to do his job without understanding all the nuts and bolts of the tool they are using. This is because that tool is her baby. The user is caring for a completely different child! Don’t let the developer’s disdain rub off on you.)
Don’t Get Complacent
The process looks straightforward – you push button A to get result B. You should be able to ignore all the babble from your SME about architecture and just write the stupid procedure, right?
Not so fast. Listen carefully. Buried in the middle of that lesson on system architecture was the tiny inclusion that, if four procedures back, you set toggle 47 to red instead of blue, pushing button A won’t produce result B, but will rather delete all your files and reboot the system! Your users need that warning!
I realize this is an extreme example, but it does happen. Sometimes you have to really dig for these gems, too. A conversation I once had with a SME went something like this:
Me: So, if I push button A, I will always get result B, right?
SME: Of course. That’s why the button is labelled B.
Me: But last week you mentioned that toggle C is directly tied to the architecture of panel F. Won’t that have an effect?
SME: No, because no one would change the setting of toggle C.
Me: No plan survives contact with the enemy. And users sometimes flip switches just to find out what they do… if it’s so bad to change the toggle setting, why is it a toggle?
SME: Because sometimes you might need…. oh.
Me: So what does the user need to know?
SME: That if toggle C has been flipped to the X position, pushing button A will delete all the files and reboot the system… I guess they might need to know to check the position of the toggle after all!
How do I Find These Things Out?!
You learn by practice. You take good notes and cross reference them. It does get easier with time. And beginning to understand the steps the SME had to follow when creating the product helps. If there is a requirements document that you didn’t write, read it. If you are captive in an Agile development environment (this kind of environment is one where being onsite has distinct advantages), make sure you’re on the invite list for the scrums. Pay attention to the SME: it’s your job to see the patterns your audience needs, and those patterns may be buried beneath layers of SME jargon. I have often described my role as a technical communicator as a translator between Geek and Common English. It’s an analogy people can understand.
And if your SME is getting peeved with your audience-related questions (after all, she’d probably rather be dealing with the project at hand rather than people), you can always bake her a batch of brownies!
Do you have any SME stories? Has translation been difficult for you in the past? Do you have anything you would recommend to fellow technical communicators to avoid problems you’ve dealt with?
If this post was helpful, see my other posts on Working with SMEs!