Re: TECHWR-L Digest, Vol 48, Issue 27

Subject: Re: TECHWR-L Digest, Vol 48, Issue 27
From: Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Mon, 2 Nov 2009 08:26:21 -0800 (PST)

Hi Steve...

I hope I'm not saying that procedures are obsolete or that we have no use for them in our writing. What I want to say is that we have to reconsider what it is we call a viable procedure. Robert Lauriston says it all... He finds lots of docs that tell him what he could have figured out on his own. Obviously, the docs were not aimed at him. If he's the typical user, then the docs are a waste of money to the degree that they took time and effort to explain the obvious.

I think writers are qualified to serve as user advocates. Also, stepping through the system and making narrative sense out of it is a good check to see whether the design works.

Hi-tech product delivery is an information management problem, and it's done by teams of information professionals. The spectrum of information management is broad, including customer input, product definition, design, code implementation, build management, bug management, tech support, budgeting... And yes, documentation. As tech writers, we're information management professionals. In that role we're qualified to contribute lots and lots... Not all of it limited to the production of pages. Thankfully, modern product development methodologies recognize this.


Hey Chris,

Your post inspires me to want to delve into the origins and history of
tech writing.

It seems odd that tech writing has evolved from probably a simple
beginning of written communication to the point where the writer is now
intimately involved with user experience design. That's not a bad
thing, it's just curious.

What qualifies a writer to perform this role? Is he/she the advocate of
the ordinary person? Is the writer somehow more "human" than the
developer, and therefore able to talk to the user in that person's
cognitive language?

I remember the days when you had to fight to get a word change into the
UI -- writers were not allowed to contribute in any way to the
interface, even from a language standpoint.

Now our ideas are welcomed, even solicited, regarding functionality,
user experience, usability, interaction design, navigation design,
screen layout, information architecture, and the rest of it.

Innovators aren't always good writers, and writers aren't always good
innovators. If our role largely makes procedures obsolete, then what
*is* our role?

Meantime, have a great weekend, all! :)



Are you looking for one documentation tool that does it all?&#160; Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at:

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:


Previous by Author: Re: Doc Design and Convention
Next by Author: Re: Doc Design and Convention
Previous by Thread: Re: HTML Help Workshop question
Next by Thread: Re: TECHWR-L Digest, Vol 48, Issue 27

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

Sponsored Ads