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:Robert Lauriston <robert -at- lauriston -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Thu, 5 Nov 2009 14:37:22 -0800
At the beginning of the process, the questions I ask about the product
are not about how it works, they're about who the intended users are.
If there no use cases and no vision of a market for the product ...
I'd be polishing my resume. I did see some of that during the dot-com
era, in which cases I had to put on my project management hat and
develop that information.
I said, "Who the users are and what they need to know." They don't
need to know about useless features. And I don't know which features
are useless until I know who the users are. Of course I have to
document the useless features, so that the developers won't complain,
but there's an art to steering readers away from that sort of thing.
On Thu, Nov 5, 2009 at 2:09 PM, Janice Gelb <Janice -dot- Gelb -at- sun -dot- com> wrote:
> 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.
>
> Robert Lauriston wrote:
>> Yeah, same here.
>>
>> There are iterative loops within this process, but overall, first I
>> ask questions about the product, the answers tell me who the presumed
>> users are and what they need to know, and only then am I in a position
>> to outline the topics and outline the deliverables.
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-
