Introduction
Technical Authors do not have high prominence in the workplace, and they don't have the best of images (as can be seen by the movie "The Technical Writer"). Today, there are a number of Technical Authors struggling to find new employment in the current IT sector, and one can find messages on Internet newsgroups questioning the future employment prospects for Technical Authors in North America and Europe. Some wonder whether the role of the Technical Author will disappear, like other careers have in the past. In this article we look at the problems faced by Technical Authors in defining their role, and make some recommendations for the future.
The problems
Let's first look at a number of issues that Technical Authors face :
1. Overlapping technologies means overlapping job roles
Technologies and software are developing in a way that means the boundaries between the programmer, the Technical Author, the Web Developer and the Trainer are becoming blurred. For example, the online Help that will ship with the next release of Windows (code name Longhorn) may look more like a Web site or a Web-based learning (CBT) system than the type of Help files we currently see. This means that some Technical Authors feel they are being "crowded out" and losing their jobs, as their work is taken on by others within the organisation.
2. The work can be done in other ways
From time to time new software or technology will come out that will lead some technology evangelists to claim you can away with the need for "man-made" user assistance. Common themes appear and reappear with each technology wave, with people claiming:
3. It's a specialist and lonely job
Many are in an environment where they are the only Technical Author in their organisation, and this can mean their career path is unclear.
4. Their contribution to the business can be uncertain.
Some people perceive what Technical Authors produce to be a necessary evil - something that needs to be provided, but not actually of any great value. So they look to keep costs, and consequently the quality, to a minimum.
So what do Technical Authors do that is of value to the organisation?We believe Technical Authors, as well as specialist documentation companies, are valuable to the organisation in:
We call this skill "information design". It is sometimes called (in Germany, for example) "information development". We believe these skills in information design have a wider application to the business than just the development of user manuals, procedures documents and Help files. These skills - organising information and providing the means by which people get that information - can help organisations fight and win the "information overload" battle.
Our recommendations
Technical Authors' skills need to be applied more widely across the organisation. In other words, create an Information Design department.
We suggest the role of the Technical Author should be redefined as "Information Designer" and the Technical Publications department should be redefined as the "Information Design" department. Doing this should help to make it clearer to everyone where their specialist skills - making large amounts of unstructured information more useful - can be applied elsewhere in the organisation.
IT departments don't have information design skills. Quality Managers don't have these, nor do marketing executives or Webmasters. The Technical Author (or Information Designer) does have these skills, and can offer these skills to anyone in the organisation that has to deal with large amounts of unstructured information.
Cherryleaf (along with other similar organisations) applies its skills to others outside of the technical authoring and software development community. For example, we work with people who are interested in improving their intranet, quality management systems, sales proposals or training courseware. So there's good reason to believe these newly named "Information Designers" could contribute in a similar way within their own organisations.
1. Carry out usability testing to measure the value of what technical authors produce
Some form of measurement needs to take place if you want to place a value on something. Jakob Nielsen () has described how meaningful usability studies can be carried out for a small amount of effort. So test to see what happens if users don't have any documentation, and how they react to different types of user assistance.
2. Get involved in the development of new software at an earlier stage
As online user assistance becomes more tightly integrated with the software, the Technical Author will need to be more tightly integrated with the development of the software, right from the beginning of the process.
3. Acquire the additional skills needed
The role today requires more than just writing. It requires skills in online information design and usability. In the future, it could require skills in writing JavaScript and developing e-learning content. However, some of the need to hack into code can probably be avoided if you use the most popular Help authoring tools. These developments in the role probably mean more training is required by Technical Authors.
4. Use the right tools for the job
The latest software from the main software vendors in this field provide more than just an authoring environment. Many tools now include content management, e-learning, scripting and support for output across a range of media. The vendors seem to have a good appreciation of the key issues surrounding the provision of user assistance and large documents.
Conclusion
The overlapping of technologies and the uncertainty of the contribution of the Technical Author does mean that the boundaries between this and other positions in the organisation are becoming blurred. Technical Authors have skills that organisations still need. Indeed, they can be applied to new areas. Cherryleaf applies its skills to other business areas and others can do the same.
This means taking a new perspective on the role. So maybe we need to say "The Technical Author is dead. Long live the Information Designer."
(c) Cherryleaf 2006
No comments:
Post a Comment