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.
> The point that I'd like you to get is that "Increases sales"
> does NOT belong in a technical document, unless the product
> is a sales-generator machine, that when you press the button
> spits out sales.
The point I'd like to get you to is that technical communication is supposed
to be task oriented. What that means is that the subject of a technical
document is the task, not the product. A technical document is a how-to
document, not a product specification.
A document that specifies the characteristics of a product is an engineering
document, not a technical document. A technical document is about how to
perform a task. Technical documents are sometimes packaged with a product,
and sometimes sold separately. But their subject is always the task and
never the product.
This is why engineers often fail to produce good technical documentation.
It's not because they can't write: most of them can. It is because they tend
to write engineering documents instead of technical documents; to write
about the product instead of the task. If there is one skill that I would be
willing to describe as core to technical communication, it is knowing the
difference between a technical document and an engineering document.
And (to get to the immediate point) the fact that the document is about the
task and not about the product means that if doing the task will increase
sales it is perfectly legitimate to put the phrase "increase sales" in a
technical document, though it would not be appropriate to put it in an
engineering document.
> The docs should also not make any relative claims unless
> those claims are specific and detailed, including details
> like: "Relative to what, exactly??"
Relative to not doing the task or to doing it differently. Again, it's about
the task, not the product.
I'm going to bring this back again to the value of the technical
communicator's role. If by "technical communication" you mean rendering
engineering documents into layman's terms, then you are adding very little
value to your company or your customers. Your function is one that is easy
to offshore, and indeed, easy to dispense with altogether. If, on the other
hand, you are promoting and enabling the more efficient performance of your
customer's tasks, you are adding real value to both your employer and your
reader. That makes you worth keeping.
As with all marketing writing -- as with all writing -- you should strive to
find the words that will actually appeal to your audience. But this does not
mean that you should not be doing marketing writing, only that you should be
doing it well.
---
Mark Baker
Analecta Communications
www.analecta.com
+1 613 614 5881
ROBOHELP X5 - ALL NEW VERSION. Now with Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more!
Now is the best time to buy - special end of month promos, including:
$100 mail-in rebate; Free online orientation on content management
functionality; Huge savings on support and future product releases;
PLUS Great discounts on RoboHelp training. OFFER EXPIRES April 30th!
Call 1-800-358-9370 or visit: http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
