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:
- Buy Developing Quality Technical Information and read it from start to finish.
- Find out who you are writing for and put yourself in their shoes.
- Research what information would really help them do their jobs (or install their microwave oven).
- 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.
- 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.
- Ask SMEs and fellow techwriters to review and edit your documentation – based on different levels of edit.
- 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.
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.
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 🙂