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.
Subject:Re: Writing to your audience From:Chantel Brathwaite <brathwaitec -at- castupgrade -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Wed, 02 Mar 2011 17:50:53 -0500
Another thing to consider is that often there is an "informal
audience." Aside from the end user, there is the informal audience of
people inside of the company who review your documentation. Some either
trust your expertise or are in tune with what the users need, but
sometimes there are others who are not. If they are the ones that must
approve the recommendation, it can be touch and go because sometimes
they want to put things in the documentation that most end users
probably don't care about, like the nitty-gritty details of exactly how
a specific algorithm works in a user manual. Often these internal
customers know the software well and want to be accurate, but don't
realize that this might confuse the user or worse, make them want to
stop reading the manual completely. Then, there are some who blanche at
the thought of putting things in that feel intuitive to them. If you
have freedom over what is in the document or if you have the backup of
management and the respect of your team, it is easy to overcome this.
But if not, even if you voice your objections, you can end up producing
documentation that people inside the company like, but the end user hates.
The compromise of course is to have different docs for different
audiences - so the internal user can be assured that the information
will show up in some piece of documentation (even if it is not the one
that they are reviewing at the moment) while the end user can have
document that addresses topics that will help them to complete their tasks.
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
