Editors doing audience analysis?

["Geoff Hart" <Geoff-h -at- mtl -dot- feric -dot- ca>]

Christi Carew, continuing the thread on editing, wrote <<I think the 
best editors are ones that have done writing at some point.>>  

Plus those who have _been_ edited. It teaches you a lot about your 
own blind spots, teaches you some empathy for those authors 
you're editing, and takes you down a few notches whenever you're 
getting too arrogant.

<<I don't see how an outside (contract) editor do audience 
analysis. I could see a staff editor doing this and can see how this 
fits into the definition of editor that I have. But I think this is usually 
done by the writer. The editor might have input, but I would expect 
writers to analyze the audience befor they start writing.>>  

The independent editor won't do a formal audience analysis unless 
asked to do so. More commonly, the editor will spend some time 
obtaining information about the audience the writers are trying to 
reach, and will then use this context to determine what kind of 
editing is required. By kind of editing, I certainly don't mean "the 
audience are idiots, so replace any words with more than 5 letters 
or two syllables". It's more a question of learning the type of 
materials the audience is familiar with (e.g., what kind of jargon 
they understand) and what the conventions of discourse are for that 
genre (e.g., the structure of a scientific manuscript is very different 
from that of a user manual). Most editors specialize in one or a few 
areas, and become sufficiently familiar with those areas to be 
conversant with the type of language and style people in those 
areas expect and can deal with.

<<I'm not sure how much editors could initially give toward user 
task analysis.>>  

One thing that a good editor can do is place himself or herself in 
the shoes of the user. That's awfully difficult for a really good 
technical writer to do, because the more you become immersed in 
a product, the more expert you become and the greater the 
distance you place between yourself and the reader. (In fact, if 
you're the one writer for a project involving multiple programmers, 
it's not unreasonable to expect that you'll eventually end up 
knowing the product better than any of the individual developers.) If 
you're a technical writer who's aware of that phenomenon, you can 
compensate for it; in the extreme case, that would involve doing a 
full, formal audience analysis, but more commonly, it involves 
taking a step backwards and consciously examining your own 
assumptions. An outside editor arrives with none of this expertise 
in the product, and thus with a much smaller distance between the 
editor and the reader. That helps you identify gaps that must be 
filled.

<<Alhtough correctness might be another issue. I would not expect 
a contract editor to be able to review a doc for correctness.>>  

That depends on what you mean by correctness. If you give the 
editor access to the product being documented, and ask the editor 
to do "fact checking", then the editor can certainly run through the 
manual and confirm that it matches the product. What the editor 
can't do is determine whether the nitty gritty technical details are 
correct (e.g., the serial number of the microprocessor being used); 
that's the job of the peer reviewers who do technical checks.  

--Geoff Hart @8^{)}  geoff-h -at- mtl -dot- feric -dot- ca  (Pointe-Claire, Quebec)
"Perhaps there is something deep and profound behind all those sevens, something just calling out for us to discover it. But I 
suspect 
that it is only a pernicious, Pythagorean coincidence." George Miller, "The Magical Number Seven" (1956)