“You’ll be working as part of a team that mentors and coaches the developers and user experience specialists to improve their technical writing skills by providing style guidance and feedback. This role requires you to be the proactive subject matter expert for user interface writing and technical documentation, and to be able to introduce new ideas and practices to the company.”
As there are no official statistics recording the number of people employed as Technical Authors in the UK, we have to make some educated guesses to get a sense of the size. Searching LinkedIn might provides some useful information.
In LinkedIn’s advanced search page, if we search the job title field for Technical Author, LinkedIn states there are 5,297 people who match this search. This would include past job titles as well as current job titles. Searching on just current job titles, LinkedIn provides 2,109 results for Technical Author. Searching on just past job titles, LinkedIn provides 2,528 results for Technical Author. It’s not clear why those two figures don’t add up to 5,297.
One of the difficulties is that people use a variety of different job titles. In addition to the 2,109 results for Technical Author, we can add the people who have these current job titles in the UK:
Technical Writer – 603
Technical Communicator – 28
Information Developer – 21
Documentation Manager – 394
That makes a total of 3,155.There may be other job titles people are using in addition to these, which would increase the numbers further.
There were over 19 million registered LinkedIn users in the United Kingdom, as of the 3rd quarter of 2015 (source), out of a UK working population of 30 million people (source), which means it’s unlikely every Technical Author has a profile on LinkedIn.
It seems reasonable to conclude there are more than 3,200 Technical Authors in the UK, but possibly not more than 5,000.
We were contacted last week by a SaaS developer who wanted to know if their solution might be of interest to companies needing to write and host their product’s user manual or online Help content. So what capabilities do Technical Authors look for in an authoring tool?
There were a few features that sprung to mind:
Multi-channel publishing (for example: publishing to the Web, Microsoft Word and PDF). PDFs are still important as a publishing option, as people still like to read good quality printed content.
Separation of look and feel from content.
Content re-use (write once, re-use many times). This is different from simple cut-and-paste.
Variables (so it’s easy to change product names).
Conditional text (content that can vary depending on the type of user or type of product).
Link management (being able to find content in the project quickly, as well as being able to manage the dependencies among links and topics).
The ability to handle larger documents (200+ page documents with screenshots on most pages)
Expanding/collapsing table(s) of contents (and even different tables of contents for different types of users).
A user-friendly authoring environment.
Version management of the content.
Ideally, there would also be:
A way for occasional users to add and edit content without breaking formatting styles, using a User Interface that didn’t overwhelm them.
Access to and shared management of the content. This is so that writers could collaborate with each other, working on different topics for publications at the same time.
Our client is looking to recruit a permanent Technical Author to join a team of writers that provides global support documentation for its range of scientific products.
You’ll be part of the team that creates and updates service-related information for scientific instrument equipment. You’ll be involved in the installation procedures, as well as maintenance and diagnostics of the internal hardware and electronics.
We’ve had an enquiry from someone looking for 1-2 Technical Authors to help out on a potential project which would start in June. The content will be created using Word and FrameMaker, and ideally you will have skills in using both applications.
They are looking for Technical Authors with:
Experience of military land vehicles and/or their components, including IT hardware and software.
Experience of documentation relating to submarines and surface ships.
You need to have a track record of at least 18 months technical authoring. Please send us your CV, plus details on on what your day rates would be if offered a 6-month contract.
Approximately 50% of a Technical Author’s day is spent writing. However, when Technical Publications teams look for efficiencies, they tend to focus on the 50% of time spent on non-writing activities, such as researching, reviewing and planning. They assume the content itself cannot be written more quickly. To an extent, they are right, as the querty qwerty keyboard is not an optimal layout.
We’ve been going through a process of transcribing our early e-learning modules, in order to have scripts upon which we can base future course updates. As part of this project, we’ve been using a free application called Plover to help us write the content. With Plover, you have the potential to create content (in Word, RoboHelp, Flare, Oxygen XML etc) at up to 225 words per minute (wpm).
Plover is based on chorded typing. You press more than one key at a time to create words. Chorded typing isn’t new – for example, it was demonstrated in Douglas Engelbart’s famous “The mother of all demos“.
Below is a five minute lightning talk on Plover and some of the emerging hardware:
So far, in my case, I’ve been able to double my typing speed. Realistically, those of us participating in this project at Cherryleaf aim to get to 180 words per minute. The reason for this is that most people speak at 160-180 wpm. At that speed, you are able to transcribe subject matter experts in real time – which means there’s no need to record an interview and then type it up at a later date.
There is a learning curve to this method, but it is based on over 100 years of theory and practice. It is tremendous fun – a bit like learning to use a querty qwerty keyboard for the first time.
Our method for creating online courses involves making an audio recording of the presenter, transcribing it, editing the script and then recording the final, video presentation. We’ve tried using speech recognition software to create the transcribed script, and it has been a deeply frustrating experience.
While speech recognition is proving successful for searching and issuing commands (using Siri, Google Voice and Amazon Echo), we’re not sure it will replace the keyboard as the way we create written content.