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.
A process is a process is a process. I get together with my IT SMEs and we
flow the program on those nifty slap-on-the-wall static white sheets in
brainstorming mode -- all of us on the same side of any furniture (us versus
the problem rather than "us-writers" versus "them-ITers" or vice versa).
After a limited time period (usually half an hour but it depends on the
complexity), we stop and take a short break, then come back and with another
color marker we insert where we _think_ the user advantages and concerns
will appear.
I clean up the resultant process map in a graphics program (I like iGrafx
Flowcharter, have used Word Draw in a pinch), circulate it to all
participants within 24 hours with an invitation to suggest corrections
within another 24 hours.
After that time, I get together with a user focus group and broadcast the
nice neat flowchart onto another sticky sheet. When the company computer
projector isn't available, I use a $14.95 light bulb paper image projector
from the Harriet Carter website. The users then get to tell us where we
were on target with their interfaces and where we missed the mark. I record
that information, add it to the first printout (in another color), and take
this back to another meeting of the programmers.
Keeping in mind that I'm usually working with a very small subsample of the
actual user base in our focus group, this nevertheless almost always results
in a good clean process that works well for everybody and minimizes the need
for that pesky user testing (the development phase where your test group
gives up and you ship the darned thing out to let the hapless users continue
the testing process for you). We're almost always catching glitches early
enough in the development phase that a minor tweak here or there can create
major improvements in meeting the users' needs and desires -- sort of like
that kewl idea of pushing an asteroid a few inches to port or starboard ten
years before it was going to smack into us.
Most programmers have had at least an introduction to flowcharting
(everybody is supposed to make one before they start writing code, almost
nobody does). If I make the flowchart at a high enough level and keep it
clean enough to maintain an intuitive flow, it can become an excellent
"common language" between programmers and less- or other-technical folks --
line workers, managers, etc.
I strongly suggest that all technical writers take at least an introductory
programming course. Pascal language is good for obtaining a good
understanding of how programming works in general, though I wouldn't want to
actually try to accomplish anything with it. Just another little tidbit for
the old toolbox.
Dori Green
Technical Writer, QMS Project
Associated Brands, Inc.
"I'm a power user, not a hacker. Please explain that again, in English this
time."
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
