I have worked as a technical author for nearly four years and have had to climb a steep learning curve. Today I am going to share with you a few of the common problems that I have encountered along the way.
Not meeting your end user
One of the most common frustrations of a technical author is never meeting your end user. If you were the author of a series of block-busting novels you could, at some point, choose to meet your readers and get their feedback. You can choose to take their feedback on board and add or cull characters in your novel or introduce new locations and storylines.
Never make assumptions as to who your end users are, instead discuss who they are with your client. Remember that your client does know your end user; they deal with them every day. This helps you build a mental image of who you are ‘talking to’ through your documentation. Some technical authors like to have a picture of their typical end user on their desk to help them focus.
Here at Armada it has been known for documentation to be written with little or no access to a finished product. Our team of technical authors have worked from developer and engineer’s notes. The product we are writing for might be impractical to transport to the writer’s office. One that comes to mind is a helicopter!
Overcome this by keeping the lines of communication open with your client; if possible base yourself at the client site. If you are struggling to understand a term don’t spend all day trying to work it out, pick up the phone and ask an expert. Remember your client is keen to get the documentation right too and most people are very helpful.
Reliance on technology
I am told that back in the day technical authors drafted their work with pen and ink before passing their documentation to a pool of typing staff. I believe this was in the same era as ‘Mad Men’ when it was also fine to smoke and drink alcohol openly in most offices! Things have changed somewhat since then and whilst technology (and the reduced alcohol intake) has made our work easier and more efficient, it can sometimes be a hindrance.
Increasingly I am using online platforms to write documentation and access customer data. This is a problem when internet access is limited. We have all experienced this frustration at some point either in or out of the office (when you start buffering during the season finale of ‘Mad Men’).
A temporary solution to overcoming this problem is to write your documentation in Word. Once you have regained access to your documentation platform, you can quickly import any Word documents. You will need to do some post import formatting, but at least you can keep your flow of work moving.
Proof reading is always a productive use of time when you have temporarily lost access to your customer data.
Writer’s block should be rare in technical authoring. However sometimes it is difficult to know where to start on a project and what angle to come in.
Overcome your writer’s block by talking to your client:
- Why have they come to you for their documentation?
- Do they want to reduce the number of calls to their help desk?
- Do you need to compile the answers to a list of Frequently Asked Questions?
- Do you need to write a complete set up guide for beginners?
Once you have the angle of your project confirmed you must write a plan. This helps you with both your time management and the structure of your project. A project plan is also useful when reporting to your client throughout the project.
Sometimes working alone on the same product for a long period can be disheartening. Even the most experienced technical authors can lose focus and productivity by getting bored. It is important to have a few tools to hand to keep you going when tea and biscuits just are not cutting it.
Take a break from your project:
- If you work as part of a team, even if you are working on different products, try proof reading each other’s work.
- Write a blog to wake up your brain and get your juices flowing again.
- Walk around and move your body to wake yourself up.
- Go outside and clear your head.
I hope I have not turned today’s blog into a moaning session on the downside of technical authoring. Instead, I hope I have passed on some practical advice based on my own experiences.
Do you have any day-to-day tips to pass on to your fellow technical authors? Get in touch or leave a comment. Have a great day 🙂