 |
 |
|
|
|
|
| |
| Product Documentation: Meeting Critical Needs on a Budget |
| |
| |
Most start-ups begin with an idea for a product or service that can meet a particular need. Technical communication expert Leah Guren explains how start-ups can produce quality documentation while staying within their budget.
|
| So You're Ready To Sell a Product |
|
Leah Guren has over 21 years of experience in technical communication and is considered on of Israel's leaders in the field. She has been a writer, editor, technical publications department manager, consultant, and trainer in the United States and Israel. She currently consults and teaches courses and seminars in technical communication for In Other WORDS. She is a regular speaker at various international conferences on technical communication and is the immediate past-president of the Israel chapter of the Society for Technical Communication. |
Initially, most start-ups focus on the kind of marketing-related documents that will help them get their message out to the market and to potential investors. But as product prototypes are developed and tested and, eventually, deemed ready to show or release, the issue of technical product documentation becomes more critical.
|
| What Is Product Documentation?
|
Product documentation differs significantly from marketing material in that it is designed for use with a product after the sale. This means that its purpose is to convey information, rather than to attempt to persuade or sell. Even the best-designed product requires some explanation: how to install it, show to set it up, safety instructions, usage tips, etc. If product documentation is not available, or if it is of poor quality, the entire burden of explaining the product is shifted back onto the company. This means large expenses in customer support and field service, wasted time for the developers, and worst of all, frustrated customers who will not be likely to buy from that company again.
One of the great pitfalls of product documentation is that many companies look at it as a necessary evil, or as an appendage to the product, rather than as a part of the product itself. Most technical products are virtually useless without documentation explaining their features and usage; in the case of software applications, the documentation is often the only really tangible collateral that a customer gets, other than a CD-ROM!
While few start-ups have the budgets to produce a full documentation suite, including printed user guides, online Help, reference manuals, and so on, there is quite a bit that can be done by paying attention to these basic rules.
|
| Meet the Product Documentation Primer...
|
Here are some tips to help anyone getting started with a documentation product for the first time.
|
| |  | Developers are not documentation experts.
The R&D team may be engineers, software specialists, or scientists. While they may write internal specifications and reports, they are not trained to write end-user documentation, which requires a very specific set of skills and knowledge. Trying to get developers to write documentation isn't only a poor use of their time, but is a guaranteed recipe for disaster, as engineers can be poor communicators and cannot manage to put themselves in the place of the user. They cannot fathom that things that they consider totally obvious need to be explained to someone. Developers can, however, educate the writer and help explain internals and features.
|
| | |
Hire an expert.
While a start-up may not be able to afford a full-time technical write, having the right contractor help produce the documentation is usually a wise investment. A trained technical writer knows what questions to ask, how to distinguish between technical trivia and something the user needs to know, and how to organize the material in a meaningful and usable manner.
|
| | |
Think task, not feature.
Both R&D and Marketing tend to get very excited about features; that is, what a product can do, rather than what it is good for. The job of a technical writer is to analyze the product and the intended target audience and to understand what that audience needs (and wants) to do with the product. Analyzing those tasks based on critical priority will help the writer document the most important tasks, even if there is a limited budget.
|
| | | Build documentation into the product.
Well-designed user interfaces, clear on-screen instructions, and even diagrams on face panels all help to reduce the need for extra explanation later. Again, consider using the services of a professional early on in the development cycle; a well-designed product is always easier to document.
|
| | | Consider an alternate format.
There is no obligation to always create a print document; in some cases, an online solution may be better for the user and more practical to implement. But remember that even a robust online solution still requires the bare minimum of print documentation, even if only a single sheet explaining how to access the online material!
|
| | | Recruit and train internally.
Sometimes a company is lucky enough to have an employee who is not only knowledgeable about the product but is also a very good writer. With professional training, that person can become the company's own technical writer on an as-needed basis. Since even the best contractor requires some time to learn a company's products and technology, the in-house approach is often the best solution for companies with extremely complex products who are looking for a long-term solution.
|
| | Conclusion |
No company should feel that documentation is too expensive or too daunting a task to undertake, because without good documentation, a product can be virtually unusable. With some early planning and the services of a professional technical writer, critical information can be documented in time for the product release.
|
The Trendletter team welcomes your comments.
|
|
|
|
|
©2002–2008 Trendlines International Ltd. All rights reserved.
Phone: +972.4.958.3323 | postmaster@trendlines.com
Directions |
Privacy Policy |
Site Map
This site contains material copyrighted by third parties.
This site
is best viewed in Internet Explorer version 5 or higher.
|
| |
| |
|
|
|
|
