TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Occupational hazard of techie tech writers From:Paula Puffer <papuffer -at- PSQUAREDDOC -dot- COM> Date:Sun, 1 Nov 1998 16:28:40 -0600
Carl Stieren writes:
Anyone who is really into technology, and who becomes a technical writer,
has advantages and one big occupational hazard:
Advantages:
* ability to understand complex systems
* ability to learn how to use the functionality of new software even when
parts of specs are missing
* ability to analyze a system and reduce it to its basic concepts
* ability to compare totally new methods or functions to existing languages,
protocols, systems
I'll agree with with analysis though I think it would be better to substitute
new technology with for new software. I, like Win Day, am not working on
computer software. I'm working on Military Hardware. I also think your second
advantage could be extended to say ability to learn how to use the
functionality of new technology even when parts or specs are missing or
contradict each other.
Occupational hazard:
* inability to explain software or functionality to a beginner (sometimes
even the inability to realize that you NEED to explain the software to a
beginner)
As a writer on the operator's manual, I have not had the inability to explain
the technology to the audience I was writing for.
Nowadays, no one is teaching every user of advanced software the
needed subjects (for example, basic programming concepts, true
object-oriented programming, principles of SGML, even TCP/IP).
hmmmm I am not sure that I follow you here.... why do the users need to know
basic programming concepts or object-oriented programming, or the principles of
SGML to run the software???? If the software or technology is a compiler then
maybe I might need to know them. The key here is audience -- you should know
your audience and your manager should at the very least have the idea of your
audience.
Recently, the program manager told me that he had made some assumptions about
the manual I was working on. He said that until he had travelled to some of the
sites, he had assumed that the operator's level manual was the least important
of the manuals we developed for the trucks - in his mind he thought that the
unit maintenance or direct support maintenace manuals were more important. What
he discovered, in talking with the maintenance staff, is the operator's manual
is the manual that all levels see because many of the follow-up tasks refer
back to operators manual in order to perform certain operations to ensure the
vehicle is working properly. This coversation with my program manager really
brough home the importance of knowing the who the end user was and made me more
aware of what i was writing and how I was writing it.
Therefore, there's a problem. Any brilliant technical writer who's into
technology and hasn't done a lot of technical writing is going to produce,
as a first draft of a first project, a document that will fail usability
testing.
huh? Are you talking about entry level writers here or writers who have lots
of experience?Regardless, I think usability testing, whether the document is a
legacy document or the first draft of a new document, is a useful part of the
documentation process (if you have the luxury of performing usability testing).
It helps clarify the writing and make it more understandable to the user thus
making the technology more usable in the long run.
