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.
It's like this: you're saying what information do they need about the thing? I'm more saying, what do they need to do with the thing? I think it's a matter of me thinking more in terms of giving directives. I formed the impression you think about telling the user this is what you can do, and I tend to think of telling the user this is what you should do.
My remark about marketing meant, it seemed to me your thinking about the users was more closely related than mine to the way in which a marketing person would think about the users. Your second question was, "For what purposes are they buying and using the product?" That's broader in scope than the kind of questions I ask, and seemed to indicate thinking about how the users see the item fitting into their business. That way of considering user concerns about the item isn't related strictly to the technical aspects of the item. When I think about why users may want the item, I tend to consider it more as a matter of tool use.
I think my way of looking at user needs and concerns is more tightly focused, that's all. And please remember that I'm talking here only about doing procedural documentation. For reference materials, or for documents that are more business related, like requirements or white papers, my approach to deciding what to put in the docs would look more like what you and Paul wrote.
I hope that clarifies things.
--- On Tue, 11/3/09, Janice Gelb <Janice -dot- Gelb -at- Sun -dot- COM> wrote:
>
> I'm not quite sure how your list and mine differ.
> Your points are all good ones but most of them
> are covered under the answer to the question "What
> information do they need in order to use the product
> effectively?"
>
> I don't think it's Marketing to try to tailor your
> documentation to the person who is most likely to
> be reading it. In order to identify what is going
> to be done with your product, and what knowledge
> you can assume and what knowledge you need to
> explain, you pretty much need to know something
> about the majority of the people who are likely
> to be reading the doc and using the product, imho.
>
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-
