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: Doc Design and Convention - to address Gene's take on this
Subject:Re: Doc Design and Convention - to address Gene's take on this From:"Gene Kim-Eng" <techwr -at- genek -dot- com> To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 5 Nov 2009 15:35:05 -0800
The other way around, I should think. What the product is supposed to do and
who its intended users are determine how it is supposed to work (they don't
necessarily tell ME, but they should tell SOMEONE on the development team). Then
the developers know what their goals are and the rest of us know how to varify
and support those goals.
I have been in development kick-off meetings where the justification for a
product was "we'd be the first to market with this," or "nobody else is doing
this," and no one with decision-making authority ever asked if perhaps the
reason none of the potential competition was doing "this" was that there was no
market to make such a product profitable. This experience is almost always a
harbinger of future disaster.
Gene Kim-Eng
----- Original Message -----
From: "Janice Gelb" <Janice -dot- Gelb -at- Sun -dot- COM>
> The answers to how the product works tell you
> who the presumed users are? I think that only
works if the people who have designed the product
have done so with presumed users in mind, answering
the same sorts of questions about user needs that
some of us have been advocating here.
The features that the product provides are not always
the features that need to be emphasized in the documentation
for the presumed user. For example, I've seen features
included in software products because the designers
thought they were cool or were jazzed because they had
figured out a way to implement them, but they weren't
necessarily features that actual purchasers of the product
either wanted or really needed.
Are you looking for one documentation tool that does it all? 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: http://www.doctohelp.com/
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! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-