Re: Important Stuff They Don't Teach In Tech Writing School

[TechComm Dood <techcommdood -at- gmail -dot- com>]

> 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.

Users don't need an advocate because products are not developed for
users, but for a profile fitting a business need or a profile within a
niche market; products are built around business models. I think
that's vaguely important and worth repeating. Users don't need an
advocate because products are not developed for users, but for a
profile fitting a business need or a profile within a niche market;
products are built around business models.

> *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.

The "poor schmuck" you advocate will ask for lots of things. Many of
those things will not be things other "poor schmucks" will need or
want. User analysis is important, but advocacy on the individual level
is corporate suicide.

> * 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.

How does that make you the user advocate? I say it makes you the
CORPORATE advocate, and as such, you MUST bring bad design into focus
for the team and not just point it out as "bad", but have a plan for
making it "better". There's value in that, and smart business people
recognize that.

> * 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.

Right, but how does this make you a user advocate?

> * 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.

See my response to your first bullet item.

> 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. 

That rule makes me want to vommit. If you (you in the general sense)
think that your role is or should be limited to waiting to be told
what to do, then I have no respect for you (again, the general you) as
a professional.

> But it *does* all boil
> down to the person sitting in front of the
> application, who needs to use it to accomplish a task.

Well, no. You're wrong there. In the end, it all boils down to the
company producing the product being profitable in selling that
product. Profitability is indeed contingent on a positive user
experience, but it is also contingent on many, many other factors,
including but not limited to development budgeting.

> 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.

I'll agree to this, but on the general level. If a small handful of
people can't get their job done with the product they bought, guess
what? They bought the wrong product.

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

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.