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.
In your discussion on the listserv, the following snip was posted:
> dare I mention that taking the tool expertise and page
> design function away from the tech writers is another
> objective.
I have seen this same idea in an ad for a Chicago firm looking for a technical
writer expressed as (very freely quoted):
> looking for a technical writer who can write.
> No desktop publishing, just real technical writing.
I understand the need for writing output and productivity. One of the reasons for
a style guide is to communicate the design decisions throughout the team. This
lets us make that decision one time, rather than several. And, it keeps us
consistent.
But, as a technical writer who believes that the most important part of the job
is "information transfer" or "development of instructional content", I am not
very convinced that writing words without an awareness of the context in which
the user will see them [the illustrations, their juxtaposition to other concepts
and topics, their place within the overall scheme of the documentation set]
allows me to ensure that the information transfer occurs. And, if that transfer
does not occur, then any apparent productivity increase is spurious.
If the writer working at the craft of information transfer is not to make these
kinds of decisions, then who is?
A recent article in Intercom talks about the interative process of understanding
that affects the structure of the document as the writer produces a document. If
all the writer is doing is writing words, I do not see how this process can
occur.
JoAnn Hackos presents an illustration in one of her classes about a two page
(front and back) quick reference card that took about 300 hours to design,
develop and write in order to present the information in the best possible way
for the end user. Without a writer who is deeply involved in user testing, design
and presentational development, this kind of project cannot be successful. [The
card reduced front-line installation service calls by a very high percentage.]
If these kinds of instructional design decisions are not made by the writer, then
they will either not be made, or they must be moved to another member of the task
team. In the one case, the user is the loser (and eventually the company who has
increased support or lower client satisfaction). In the other, I am not sure that
you have gained any productivity advantage.
