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.
Not only that, but often, the programmers want to tell you want the system does.
In fact, they might want to spend a long time explaining about a
really neat feature that they spent a long time developing, but in
itself is not really so useful to users.
The technical writer however, wants to tell the user how to perform
specific tasks using the system.
That is a major difference and why it is important to use the system
while documenting.
On 2/25/08, Borowik, Kristy <Kristy_Borowik -at- lcca -dot- com> wrote:
> I've been a technical writer for only one company, and more often than
> not, I learn the system and write my instructions from scratch, from how
> I see that the software works. I'm not always right in how a user should
> do something or how managers would want our users (Note: All of our
> software is for internal use) to use a particular feature. So I always
> have a SME check my draft when I'm done. If necessary, I'll have another
> writer double-check my work by following along in the system and make
> sure that my words are understandable and accurate. It's not unheard of
> that a process would work one way when I write it and then another later
> after they change the software, so double-checking just before release
> is a must.
>
> There are rare instances when I am not allowed access to certain
> software, such as our payroll system, and so I do have to rely on the
> programmers and the SME for accurate instructions. Usually I find steps
> that are completely unintelligible and I'll have to meet with the SME to
> have her show me the process on her computer. Only then could I ever
> understand what she meant to say. I just don't understand how people can
> write and feel confident in their documents if they can't check the
> accuracy themselves. Programmers don't always use the right words, and
> they rarely use the exact terms (field names, etc.) as shown on screen.
> And who gets all the screen shots for the document if not the writer? In
> my company, programmers get paid more than writers, so it only makes
> sense that the programmer not be bothered with getting screen shots so
> they can spend their time programming.
>
> Must be nice to do a quarter of the work and still get paid so much...
>
> Kristy Borowik
> Training & Technical Publications Developer
>
> ------------------------------
>
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-