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.

Greg Holmes

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.



Follow-Ups:

Previous by Author: Re: Why so few medical techwriters
Next by Author: Re: Important Stuff They Don't Teach In Tech Writing School
Previous by Thread: Re: Important Stuff They Don't Teach In Tech Writing School
Next by Thread: Re: Important Stuff They Don't Teach In Tech Writing School


What this post helpful? Share it with friends and colleagues:


Sponsored Ads