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.
> > Whenever people (on this list and elsewhere) earnestly utter
> > "know your
> > readers/users", I have to chuckle.
> > How do you writerly folk, who work for companies that make esoteric,
> > tens-of-thousands-of-dollars-per-unit products for technical users
> > live on the other side of the world, ever manage to become
> > acquainted with those users and their documentation needs?
> I thought that one of the cardinal rules of *any* writing is to know
> audience. "Knowledge" doesn't imply intimate knowledge, such as a
> person-to-person meeting or becoming "intimately acquainted" with
> is knowledge of the user of the document as in knowing the user's
> level, the user's purpose for having the document, and the user's
> language skill. Additionally, "audience" (or "readers" or "users")
> imply a specific person or specific group of persons, but "audience"
> general class of person that the writer should know.
> For example, a document prepared for recent high school graduates
> written for that audience, so the writer should know how to write for
> school graduates. Such documentation should not contain complex terms
> require a college education to understand. A writer doesn't need to
> every high school graduate that uses the document to know how to write
> high school graduate. So I really don't understand the issue here.
> must know the audience of their documents.
> Perhaps audience knowledge is one of the factors that encourages
> writers with a developer background in the technology being
> Those people have a better knowledge of the audience than somebody who
> does not have that background.
So, you seem to be saying:
"Be one of the people to whom your documentation is addressed"
"Make educated guesses, based on assumptions about the people to whom
your documentation is addressed."
Is that a good summary?
One way that we've acquired developer knowledge of customers' needs is
by hiring the occasional developer away from a customer. But that works
only for a while (knowledge gets stale when you leave an environment),
and addresses only a segment of our total audience for a given product.
We always had to have other reasons to hire that developer (i.e., they
knew crypto stuff and were highly proficient in the required languages).
Even so, it doesn't do me any good (as the lone writer for this division
(and its product lines) to hire a writer from one of our customers.
Given that they'd be replacing me, and would take time to learn the
parts of our world that they didn't already know, that doesn't do a lot
for my bottom line, and it doesn't do a lot for my employer to just
replace one writer with another and suffer a brief dip in productivity
Besides, we have customers for each of our products who are in sometimes
vastly different spaces, and we can't hire one writer from each major
rity/....). Nor can we reasonably hire one-fifth or one-sixth of a
writer from each space (at least, it's not reasonable to me to push
myself out of a job in such a pursuit) - besides, we'd then need an
editor to keep them all writing with the same "voice".
Nor do we want to hire engineers or technicians away from our customers
and turn them into writers (if nothing else, goes back to that replacing
one general-purpose bod with many specialist bods).
As well, I mentioned that most of them live in other countries, and
there'd be the problem of getting them here with work permits and all
Ok, maybe I'm being a tad facetious. But the general idea seems to
So, what did you really mean? :-)
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-