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 ( was TECHWR-L Digest, Vol 48, Issue 27)
Subject:Re: Doc Design and Convention ( was TECHWR-L Digest, Vol 48, Issue 27) From:Robert Lauriston <robert -at- lauriston -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Wed, 4 Nov 2009 08:36:08 -0800
By focusing narrowly on technical concerns you're excluding the
specific business contexts in which the tool will be used and thus
perhaps industry-specific warnings and tips that could be helpful to
users.
Whether that matters probably depends on how varied the product's uses
are in practice.
Also, a good technical writer should think like a marketer to the
extent that the docs may be used as presales tools.
On Tue, Nov 3, 2009 at 10:27 PM, Keith Hood <klhra -at- yahoo -dot- com> wrote:
> ... 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. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-