Posts tagged ‘Technical writing’

Becoming best friends with Subject Matter Experts

A subject matter expert or SME (commonly said ‘smee’) is a person who has expert knowledge on a particular topic. This is normally due to the topic being the job they do or system they use every day. When on project as a technical writer, a SME is your best friend. In fact, SMEs tend to be the ones who will be using what you’re working on when you’re finished, so not only do you have to extract the information from them, you have to present it in a way they like too. You basically have to be their best friend.

Establishing this relationship with SMEs can sometimes be the most challenging part of the project. They’re often still doing their normal job while the project runs, so straight away you’re coming in from an annoying angle. But if you do the work well, and get them involved early, you’ll find it’s far easier.

The best way, both professionally and personally, to get SMEs on board with a project and its aim, is to get them involved as soon as possible. And by involved I mean with the project purpose, direction and expected outcomes, not just with the piece of work they can help with. If they know where their piece fits in the project puzzle they’ll naturally want to have more of an input.

It also helps if you explain your involvement to a SME. Like why you’re there, what you’re doing and how you’re going to do it. A useful approach when explaining this is to have already got stuck into the work and created what I call a ‘skeleton draft’ (or two). Having something to put in front of the SME is always helpful. The drafts make it easy to identify gaps and ask good questions, and show the SME straight away the style of work you are going to produce. If you’ve got time you can also work with the SME to scribble all over it touching up content, removing things that don’t work and highlighting the things that do. Then after a bit of a touch up you not only have a template, your SME has been involved in its creation from the get-go.

When a project changes from an interruption to being interesting, meetings are suddenly accepted and new records are set for turnaround times. Without any work tension you’ll often find that the SME is a really cool person too, while some even have an opinion on sport (a good thing)! I’ll admit that there are occasions where this isn’t foolproof, like if you’re developing something that will remove someone’s job, and that someone is the SME… but ideally, knowing how to do the job well leads to good SME relationships.

Do you have any pointers for building a good relationship with SMEs? Have you worked on any projects where your relationship with them was particularly good, or particularly awful? I’d love to hear your examples.



June 29, 2011 at 10:54 am Leave a comment

Defining technical writing

“So what do you do?”
“I’m a writer”
“That’s cool, what do you write about?”
“Oh not like that, I’m a technical writer”
“Oh right, okay. So umm… what’s that?”

This is how the conversation usually starts. The next part varies depending on the most recent projects I’ve done. Sometimes I’m a website developer, other times I’m a trainer, but most of the time I’m just plain confusing. Technical writing just isn’t one of those jobs everyone has heard of. Not surprisingly either, considering I am one and don’t know how to really describe it.

So I did some research and it appears I’m not alone. In business terms, technical writers are traditionally bad at expressing their value. We’re even worse when it comes to defining the product we deliver. Businesses tend to hire us to create documentation because they see it as necessary evil, rather than an opportunity to add value. And ‘adding value’ is exactly what a good technical writer does.

But I can’t simply describe my job as ‘adding value’. That’s even more ambiguous than where I started.

What I mean is that when a user reads some documentation for the first time their experience has a flow on effect. A satisfied user will come back (loyalty). They will talk about it in a good way (promotion). And in work situations will be able to do their job faster (efficiency).

So, to put it simply and not sound too boring, next time I’m in the above conversation I think I’ll just say “I keep a business’s users happy by making things easy to read, easy to find and easy to understand”. If they’re not satisfied with that and ask how, I may have to give them the long-winded version…

Technical writing is about modifying language and structuring information specific to users’ needs. We technical writers are communicators, and we have the ability to work directly with users and subject matter experts not only to extract information, but to learn directly from their perspective. This approach allows us ask the right questions, pinpoint assumptions and above all, tailor the information in a way that will be easiest for users (especially new ones) to understand.

We often take our language skills for granted (I really should stop generalising, but I’m sure I’m not alone here), which is a key element of being a technical writer. We don’t take long to figure out how to put something in words, editing time is minimal, content is clean and consistent, and more often than not we’re so used to typing that we do it at an alarming speed. I know this is starting to sound like a pitch, but I’m still on my ‘adding value’ tangent.

Do we have any other technical writers reading this? How do you describe what you do to friends? Do you actually call yourself a technical writer? Or are you a documentation developer, instructional designer, or something similar? And more importantly, have I completely overlooked the easiest way to answer the “what do you do” question?


May 11, 2011 at 8:36 am 7 comments

Information Mapping Partner

Recent Posts

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 16 other followers