One of the most common questions we get asked is for advice on becoming a freelance Technical Author. To help address that question in depth, we written an ebook, which you can purchase via the Cherryleaf website.
This guide answers the key questions people have when considering a freelance career as a Technical Author. It is focused on starting out as a freelance Technical Author in the United Kingdom, and in the IT and medical equipment sectors. However, many of the sections will also be applicable to other countries and other industry sectors.
Here are the slides the panel put together for the Adobe Day Europe discussion on “Assisting the millennial user – challenges and opportunities in the decade ahead”. We didn’t get time to cover all of the topics in the time we had available (unfortunately some of the previous speakers overran their time slots). Continue reading →
Editor’s Note: Introducing a new guest blogger to Cherryleaf’s blog: Dr. Tony Self of HyperWrite.
Where are all the technical writers?
I have often wondered why there are so few technical writers in the world.
In my country, Australia, the Bureau of Statistics (ABS) estimates there are over 2,000 technical writers within the total workforce of 11.65 million people. The Australian Government groups technical writers into a category called ”Journalists and Other Writers”. That category of writer has shown little growth over the last decade, and in 2011 represented just 21,400 people.
With the recent media attention on Yahoo’s announcement that it is banning its staff from “remote” working, we thought it might be useful to look at the case for and against Technical Authors working from home.
The case for allowing remote working
They can do their jobs more productively without interruption from others. When Technical Authors are writing (which is approximately 50% of their time), it can often help their concentration if they can work in a distraction-free environment.
There’s less need for office space and related costs (telephones, desktop computers etc).
“Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings.”
Being a Technical Author is one of those roles where remote working can work well. However, it’s best to be able to have both options available – to have people who can come into the office within a short space of time, should there be an emergency. There’s a great deal of value in meeting people face-to-face, and to be part of a company culture (especially within startups), but it can help enormously if you can write in a distraction-free environment.
If you do work from home, you need to have a productive working environment, and be able to be self-disciplined.
We’ve been working on a white paper that looks at how User Assistance can be more effective and developed more effectively when you’re working in an Agile environment. The white paper should be published in the next few weeks, but here’s a sneak peek at one of the issues we discuss: the lack of time available for creating User Assistance.
Agile’s iterative release of products, and sometimes frequent changes to the functionality and the User Interface, can make it difficult to create the user documentation. The Technical Author can end up having to rework content they’ve written, delete sections on functionality that’s no longer part of the product, and add information on features that have been introduced towards the end of the project. If the Technical Author waits until the product has been completed, they can find they have very little time available for writing the user documentation.
The reason why Science and the dark art of persuasion interested me, was because we’re noticing the techniques of persuasion appearing in some Web-based Help. Indeed, we cover some of these techniques in our advanced technical writing course. So, although the debate was on what scientists should know about persuasion, and whether they should ever use these techniques, it seemed likely that the information would also be relevant to technical writers.