Technical communication

From SME to techwriter in 7 steps.

I work as a professional technical writer even though I am really a subject matter expert. This provides a lot of challenges and opportunities.  Before my current job I couldn’t care less about the uses of en and em dashes, something that has now taken up at least an hour of my life. More importantly I did not have a clue of how to produce quality technical information. What I have is the problem solving skills and natural curiosity of an engineer – willing to analyse and solve any and every problem I run into. I also live by the philosophy that the best way to learn is by doing. The quickest way to learn a new skill is to find someone who already masters that skill and mimic as best you can – naturally taking into consideration that your problems might not be the same as the expert’s – and filtering accordingly.

The first thing I did when starting this job was to find a book on technical writing with good reviews – Developing Quality Technical Information – and then starting to produce my very first user manual. The result left much to ask for – but still had the focus on task orientation – with clarity and concreteness being the most important properties. Choosing this book as my techwriter’s bible was a good choice as it’s easy to use, easy to understand and it’s easy to find what you are looking for in terms of specific topics.

The challenge I now face is how to get a grip on using topic based authoring and structuring content so that it’s easy for my users to find what they are looking for – hopefully making their life a bit easier – because that’s really what user documentation is all about – helping users perform their daily tasks, isn’t it?

The title of this post seems to promise a seven step procedure, so here goes…

To produce quality user documentation – follow these steps:

  1. Buy Developing Quality Technical Information and read it from start to finish.
  2. Find out who you are writing for and put yourself in their shoes.
  3. Research what information would really help them do their jobs (or install their microwave oven).
  4. Write down the questions your users need to have answered, write down what task they need to perform and what reference information topics they need to have at hand.
  5. Produce the user documentation – using the book as your bible. Make use of the checklists in the appendix for checking the quality of your documentation.
  6. Ask SMEs and fellow techwriters to review and edit your documentation – based on different levels of edit.
  7. Kick back and enjoy the feeling of having helped Mr Smith install his new microwave oven in time to surprise his wife with a real microwave gourmet dinner.

3 Replies to “From SME to techwriter in 7 steps.

  1. Surely being an Engineer does not make you an SME. You would only be an SME if you were working on a product you had developed, or had expert knowledge in. Otherwise you are ‘just’ a technical writer with a lot of the ‘technical’ in you.

    1. Hi Samuel, thanks for your feedback!

      I haven’t thought about it that way – could you please tell me about more about how your resoning goes?

      I assumed having enough technical knowledge to be able to write requirements for what the software should do qualifies me for SME acronym. I have a lot more domain knowledge than technical writing knowledge, and I would be able to develop the product if I was put in that position.

      To indulge you, maybe we can call me a subject matter enthusiast (SME), even though I lean more towards expert than enthusiast 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *