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.
Damien Braniff is currently doing some research into <<... how ID
[information design] can help the TW. Basically I'm looking at the
different stages in the writing process and how ID can help/be applied at
each stage.>>
Have a look at Karen Schriver's "Dynamics in document design" (Wiley, 1997).
I don't think you can currently find anything else even close to this
comprehensive.
<<everything I've seen/read so far in the ID field (as applied to TW) seems
to be common sense>>
"Common sense" is my favorite oxymoron. Sense is anything but common. And
even when the sense is common, the will to use it is often lacking. Probably
one of the most common complaints in techwhirling is "I would've done it
better if they'd let me/given me the time/given me the money/whatever".
<<Stage 1 - Job assigned: We're told what needs to be done - User Manual,
Web page etc. No ID here>>
Nope. This is where you spend a few moments pondering your audience and (if
you're allowed) actually talking to them to find out their needs and the
audience characteristics that let you meet those needs. In my experience,
"we're told what needs to be done" usually misses at least 1/3 of the real
needs, and the remainder often targets the wrong needs or targets the right
needs ineffectively. You listed this as stage 2, but ideally this audience
analysis should be part of the group that defines stage 1 in the first
place. And that definition should be based on a sound understanding of user
needs, which is what ID is all about. The problem with doing the data
gathering as step 2 is that by the time you begin, the project has already
begun rolling unstoppably downhill and acquiring so much momentum that it's
often too late to change the initial design by the time you discover that
design was wrong.
<<Stage 3 - Outline and Organise: Structure and layout of the document etc.
ID - style, doc design, readability etc. Stage 4 - Graphics: Appropriate use
of diagrams/pictures. ID - 'best use' of graphics - type, positioning etc.
Stage 5 - Write
Create the words. ID - again style, structure etc.>>
All seems quite reasonable.
<<Stage 6 -Edit/Review: Self explanatory - no real ID used here?>>
Yes and no. Any really good editor must edit with a clear understanding of
the audience needs, the publisher's needs, and how to reconcile the two. In
terms of the review process, you need a good grasp of your audience
(reviewers) to be able to coax them into producing effective reviews, not to
mention using this knowledge to defend your manuscripts against brain-dead
review comments. Plus, part of the review process should ideally involve the
audience. Up until this point, you've been working with (hopefully sound)
theoretical principles, but the gap between theory and practice is often
quite wide. In fact, the earlier in the process you can test your docs on
real readers, the more likely you are to apply the theory correctly.
Moreover, any problems you spot early in the writing process are problems
you can prevent from becoming part of all your subsequent writing. That's an
enormous time saver and quality improver.
<<Stage 7 - Deliver>>
The ID component here is that all information design should be iterative: in
short, the fact that you've delivered your product doesn't mean you're done.
Once it's out in the field, you're effectively conducting the equivalent of
software beta testing: you've produced what you consider to be a good
product, and now you're going to collide hard against the reality of your
audience. The results of this collision will shape your next attempts,
either for a checkpoint release or for a subsequent version.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"I vowed [that] if I complained about things more than three times, I had to
do something about it."--Jon Shear
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
