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.
Re: Important Stuff They Don't Teach In Tech Writing School
Subject:Re: Important Stuff They Don't Teach In Tech Writing School From:Greg Holmes <greg -dot- holmes -at- gmail -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sat, 28 Aug 2004 21:48:07 -0400
"Gene Kim-Eng" wrote:
>Nevertheless, the phrase "advocate for the user/
>customer" still raises my blood pressure every
>time I hear it.
Well, sorry, but sometimes the user *needs* an
advocate, sad though that is. If everyone just
works to rule (or maybe in IT call it "works to
scope") the best you'll wind up with is mediocre.
And of course, you don't always get the best
outcome, so it can be a lot worse than mediocre.
*Somebody* should advocate for the poor schmuck,
if too many people are just trying to mechanically
check off requirements while pretending that
they are making something good.
Mind you, I don't go off thinking "I'm the tech
writer, so I need to be the user advocate". It
just often works out that way. I think that
there are several reasons the tech writer can
end up in that role:
* Development likes to push interface problems off
on documentation. "It's confusing? Oh, we'll just
handle that in the procedures." Not if I'm in the
design meeting you won't; not without at least some
questions asked and suggestions made.
* The tech writer can be one of the first people to
get a good look at the design who does not have a
vested interest in preserving it unchanged to
completion.
* Design problems often come to light when you write,
or even just think about how you are going to write,
step-by-step procedures for accomplishing tasks. Why
this doesn't show up in the "use cases" used to draft
the design is beyond me, but I can often just see in
my head the crazy, convoluted steps that I'm going
to have to write, so I ask "why does it work that
way"? Maybe there is a good answer, but often there
is not.
Of course, I could just work to rule too, sitting there
in the business requirements or technical design
meetings, listening for "documentation issues" like
a good little tech writer. But it *does* all boil
down to the person sitting in front of the
application, who needs to use it to accomplish a task.
In the long run, it's not a good thing for anybody if
that person (the end user) has too many obstacles
placed in his way.
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.