Re: Doc Design and Conventions

Subject: Re: Doc Design and Conventions
From: Robert Lauriston <robert -at- lauriston -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Sat, 31 Oct 2009 10:18:28 -0700

I think the main qualifications are the ability to learn whatever
you're writing about quickly and the ability to explain it in plain
English (or whatever kind of English is appropriate for the audience).

At least in software, I think good tech writers end up knowing a lot
about UI design because we have to compensate for bad UI design. I've
often been the first person to actually approach a product from the
perspective of an end user, and have logged a zillion usability issues
about sloppy ad-hoc design by programmers who didn't really understand
who would be using the product to do what.

I have more than once documented ~40-step procedures with the main
goal of persuading the product manager that the UI needs to be fixed.

I'm not sure what you mean by "largely makes procedures obsolete."

On Fri, Oct 30, 2009 at 8:15 PM, Janoff, Steve
<Steve -dot- Janoff2 -at- teradata -dot- com> wrote:
> 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?

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:

Doc Design and Conventions: From: Chris Despopoulos
RE: Doc Design and Conventions: From: Janoff, Steve

Previous by Author: Re: Doc Design and Conventions
Next by Author: RE: Spend the noun
Previous by Thread: RE: Doc Design and Conventions
Next by Thread: 508 Compliance - Common Readability Issues

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

Sponsored Ads