Why Choosing the Correct Type of Communication Product Is Important

Jenny asked Chip to write a reference manual for a software application. When she first described the assignment to Chip, Jenny said that the reference manual would serve two audiences: end users, who would get basic instructions for the using the software, and "technoweenies," the programmers who comprise about 10 percent of the audience and who would use the reference to tailor the software to needs of a particular organization. She estimated that the reference would be 600 pages.

After looking into the situation, Chip realized that the reference would not meet the needs of end users. They had no need for 80 percent of the information intended for the reference. Furthermore, they needed step-by-step instructions, the reference would describe everything in more general terms. Most importantly, Chip figured that end users, who comprise 90 percent of the population, only need about 120 pages of the information; the company could avoid a significant printing expenses if he developed separate user’s guides and references, and only printed the reference for those users who need it.

As this example is intended to illustrate, although clients might request that you develop a certain type of communication product when they first discuss a project with you--a type such as a user’s guide, references, technical reports, marketing brochures, or tutorials--you might better meet your client’s and users’ needs by suggesting an alternative.

Furthermore, when you choose a type of communication product, you not only choose a product, but you initiate an entire set of expectations among users. When people think of a user’s guide, they expect it to contain certain types of information. For example, they expect step-by-step procedures for the most common tasks, a table of contents that immediately directs them to the task, and illustrations. People expect user’s guides to be written in the second person. Similarly, when people think of a web page, they expect it to contain links to related information.

The technical term for a type of communication product is a genre. In the field of rhetoric, a genre means "typified responses to events that recur over time and across space and that emerge in the social context of communication practices" (Berkenhooter and Huckin, cited in Killingsworth, 1996, p.107). Each given genre has a group of characteristics associated with it and to be fully considered as an example of a certain genre, a communication product must contain all of those characteristics (Foss, 1991).

In practical terms, a genre refers to a particular type of communication product, such as a user’s guide or a reference. Users approach each of these communication products with a set of expectations and, to effectively communicate with users, technical communicator must meet these expectations. As visitors to a store expect to find merchandise, prices, and sales people, so users of particular types of communication products expect them to contain certain types of information, provide certain means of physical access to the information, and to present the information using a certain writing style.

The next several sections:

• Introduce the most common types of technical communication products and the types of expectations users bring to them
• Identify key issues to consider when choosing a type of communication product
• Present an example of choosing a type of communication product

Top

The 13 Most Common Types of Technical Communication Products

Technical communicators develop many types of communication products. The majority fall into a category typically labelled "documentation" because they document the procedures for using and servicing products and policies, and that document all of the the issues associated with particular topics. In some cases, technical communicators share document "basic" scientific and technical information, such as the results of laboratory and field studies and theoretical concepts. But as mentioned earlier in this book, merely documenting information no longers ensures that people will actually use it. Organizations need to sell or "market" technical products and services (and, to some extent) concepts as well as train users in them. The range of communication products that organizations ask their technical communicators to develop, therefore,also includes these types of materials.

The next several sections introduce you to the 13 most common types of technical communication products. They fall into the following categories:

• That explain products, services, and policies, including user’s guides, help, service guides, references, and policies and procedures manuals
• Share "basic" scientific and technical information, including technical reports and articles
• That market products and services, including proposals, catalogs, brochures, and newsletters
• That train users, including tutorials and job aids (quick references)

Certainly technical communicators develop other types of communication products. But rather than overwhelm you with every possibility, I choose, instead, to introduce you to the ones you are most likely to encounter in your work in this field.

Communication Products that Explain Products, Services, and Policies

Communication products that explain products, services, and policies are the ones that, in the past, others have referred to as documentation. These communication products explain how to apply technical products, services, and policies in the contexts of their own needs and still represent the most typical projects handled by technical communicators. Technical communication products that explain products, services, and policies and that are commonly designed developed by technical communicators include:

• User’s guides
• Help
• Service manuals
• References
• Policies and procedures manuals
• Wizards

User’s Guide: A user’s guide explains "how-to;" it tells users how to perform the most commonly performed tasks with a product or service. User’s guides are typically printed. For example, user’s guides for software packages acquaint users with the features of the software and tell users how to install the software, use it, tailor (customize) it, and solve problems that might arise when using it (called troubleshooting). User’s guides for cars acquaint owners with the controls on the dashboard, and tell users how to maintain the car and troubleshoot common problems.

Users typically consult user’s guides in two instances:

• With an immediate need, either to find out how to do something, whether a particular task is possible, or why something isn’t working as expected. In such instances, users only consult a small section of the information product.
• To become familiar with the product. In such instances, users read entire sections or read the communication product in its entirety.

Users expect the following material in a user’s guide:

• Something to acquaint them with the product, such as a picture of the product or a "tour" of features
• Installation or setup instructions
• Instructions for performing the most common tasks (and if a task can be performed many ways, descriptions of just one or two of those ways)
• Instructions for tailoring--customizing--the product
• Instructions for troubleshooting

In some instances, users expect advanced tips and techniques.

To find information in a user’s guide, users consult:

• The table of contents to find a particular chapter
• Running headers and footers, which are printed at the top (header) or bottom (footer) of the page or screen and that provide the page number and the name of a section or communication product, to help pinpoint the exact page
• Headings and subheadings to locate particular information on a page
• Charts and tables to locate specific facts
• Glossary to locate definitions of unfamiliar terms
• Index to locate specific topics; for users looking for specific facts, this is often the first part checked

Users expect user’s guides to be written in the second person and expect a polite, direct writing style. They expect instructions to be written in the imperative mood-that is, as directions. In these instructions, users expect us to provide lists of materials needed, examples, and definitions when appropriate. Users of user’s guides tolerate some technical jargon, but prefer no more than necessary.

Help: Help is a special type of user’s guide for software that is available to users online as they use software applications. Users consult help in these types of instances:

• Before starting a task, to find out whether it is possible to perform and, if so, how to perform it.
• In the middle of performing a task, for a reminder of how to complete it.
• After performing a task, to explain unanticipated results.

For example, suppose a user is using some software to perform a task that has not been performed in 3 months. The user presses the F1 key, which displays help, then searches for instructions on how to perform the task.

The name Help is probably a misnomer because it sets up the expectation that help will really help. When software companies first introduced help, they rarely met that expectation. In fact, in many instances, users would try to display help information and the system would respond with the message, "Help not available now."

System designers have since resolved that issue and technical communicators have helped to train users in what to realistically expect--and not expect--from help. As a result, users now have the following realistic expectations of help:

• Start either by pressing the F1 key (almost universal on all systems) or by choosing the option, Help
• Offers, at the least, these types of information:
  • "What’s this" help, which explains the various elements of a screen and tells users how to respond
  • Procedural help, which provides step-by-step instructions for performing tasks
• Offers, at the most, these additional types of information:
• Examples and demonstrations, showing users how to perform specific tasks and the likely results
• Tips and techniques, that quickly acquaint users with aspects of the software that they might not have otherwise noticed
• Cue cards, which display, one instruction at a time, the instructions for performing tasks
• Wizards, which automatically perform tasks for users, except for those steps in which users must make choices (for example, a wizard can automatically create a meeting agenda, but might prompt users to choose the appearance of the agenda and to type the names of participoants in the meeting)
• Access to online tutorials (which I describe in a later section)

To find information in help, users consult:

• Contents, which lists the major sections within help; some communicators group these by types of information, such as reference information and examples and demos, rather than subject, such as installing and troubleshooting
• "Search for help on," which acts like an index in that it lets users type in the term they seek information about, then displays all of the index entries that mention that term
• Index, which lets users scan through the entire index
• Links, which let users directly "jump" from one topic to a related one by clicking on on a highlighted term; links are sometimes called hyperlinks because the technology used to link topics so that users can move among them without going through an index or table of contents is called hypertext

Ideally, when users display instructions for performing a task, those instructions should be visible to users as they perform the task. This is called stay-on-top help becuse the text "stays on top" of the screen when users perform the task.

The writing style for help is much like that of a user’s guide. Because the information is displayed online, however, technical communicators should make generous use of visuals. This might be difficult, however, because many organizations are restricting the use of visuals in help to limit the size of help fiiles.

Service Guide: A service guide is a special type of instruction manual that tells trained service representatives how to repair a piece of equipment or how to resolve a problem with software. Service representatives usually receive training in how to use service guides. The service guide for a computer is an example of a service guide. The repair manual for a washing machine is also an example of a service guide.

When users consult service guides, they are usually working in challenging circumstances. Their clients have usually tried, without success, to resolve the problem on their own. The broken equipmet or the non-functioning software usually brings business to a standstill, and they often pay for the service representative’s time, so the clients of the service representative are anxious for the service representative to resolve the problem as quickly as possible.

Users expect the following material in a service guide:

• Procedures helping them to isolate the problem and, once isolated, instructions on how to fix te problem. Users do not expect explanations of the problem; most of them have sufficient technical knowledge to determine that on their own.
• Illustrations, if they would be useful in isolating and resolving the problem. For example, users of a hardware service guide might appreciate illustrations of the parts of the hardware, so that they can match the parts they see with their names and purposes.

Service representatives generally expect to receive training in using the service guides. Many service guides use unique formats that are not, on first glance, intuitive, but have proven extremely effective with their users. To make most effective use of this training, many organizations follow a standard format for all service guides. In addition, to find information in a service guide, users consult:

• Table of contents
• Bleed tabs, , which are tabs that are printed on the outside edge of the page and tell users what’s covered on the page.
• Running heads
• Headings
• Charts and tables, which summarize error codes and other identifiers intended to simplify problem isolation
• Lists of figures
• Index

In service guides, users generally expect a directive writing style that extensively uses technical terminology.

Reference: A reference is an encylopedic listing of all major topics on a particular subject. A telephone directory reference. So is the Physician’s Desk Reference, as are the programming references provided with software. Programming references list all of the commands that programmers can use to create their own applications using that software .

Users consult a reference to look up specific piece of information. The subject might be broad, such as all of the commands used for copying information or all the medications used to treat influenza. The subject might be tightly defined, such as the use of global characters with the DOS command, diskcopy, or the side effects of a certain influenza vaccine on patients with pacemakers. Users generally do not read references in their entirety.

Users expect the following material in a reference:

• Comprehensive coverage of the subject, with every major topic listed and thorough descriptions within each. For example, if a programming language has 118 commands, users expect listings for each. If doctors have access to 1 089 drugs, they expect their reference to describe all 1 089 of them.
• Alphabetic listing. User expect the reference to begin with A and continue to Z.
• Expect everything about the topic. If, for example, a particular command has 7 options, users expect the reference to describe all 7. Similarly, if a drug has 6 side effects, users expect the reference to describe all 6.
• Examples and illustrations to explain concepts.

In addition, users have specific expectations for certain types of references. For example, users expect programming references to include a description of the command, a diagram showing the syntax--structure--of the command, a description of each parameter with the command and the options available for each parameter, an comprehensive discussion of considerations for use, and examples of commands that handle particular situations.

To find information in a reference, users consult:

• For references with several printed volumes, the spine of the reference to make sure they are consulting the one that is likely to contain the entry. (For references with several online disks, users would check the disk label.)
• Running headers and footers to locate the likely location of the article. As part of the running header or footer, users expect to see the name of the article described on the page or screen. For example:

diskcopy command - 188

• Headings to locate topics of interest once users have located the page of interest
• Subheadings to locate particular aspects of the discussion

For extremely long entries in a reference, some communicators begin the article with a table of contents directing users to specific sections within the entry. Many references do not have a comprehensive table of contents, however. (Encyclopedias don’t, for example.) Some references have indexes, other do not.

The writing style used in references is direct, explanatory, and terse. In fact, references often use sentence fragments and lists to present information. They generally do not give step-by-step procedures; communicators expect users to integrate the information and determine for themselves how to use it. Communicators expect users of most technical references to have a certain level of technical expertise and use technical terminology. However, because many users might not be familiar with the terms, communicators also provide definitions of the terms, at the least, within a sentence and, at the most, in a glossary.

Policies and Procedures Manual: A policies and procedures manual is a communication product that lists all of the policies used within an organization, or for a particular purpose, and provides instructions for administering them. In its encyclopedic coverage, a policies and procedures manual is a type of reference. With its procedures for policies, this type of communication product is a type of user’s guide or instruction manual. The documentation needed to apply for ISO 9000 certification is an example of policies and procedures manual, as is a corporate safety manual. (ISO 9000 is a quality standard of the International Standards Organization that requires organizations to document all of their procedures. ISO can certify that your organizations meets this standard; some organizations seek this certification because their customers require before they will conduct business with them.) Although communicators typically use the term "manual" to describe this type of communication product, policies and procedures are increasingly printed online.

Different types of users consult policies and procedures manuals, each with a different type of purpose in mind. The use usually depends on the user’s role within an organization. Managers consult policies and procedures manuals for three primary purposes: to determine their responsibilities, to assess whether an employee is eligible for a benefit or covered by a particular policy and, when seeking to administer a specific policy, the procedures on how to do so. Managers usually learn how to use their organizations’ policies and procedures manuals as part of their training for the job. Employees consult a policies and procedures to assess their eligibility for a policy and for procedures on how to apply it. Administrators, who usually have the responsibility of ensuring compliance with policies and procedures, consult the manual to train for their jobs and to make sure that a particular policy is being administered properly.

Users expect the following material in a policies and procedures manual:

• Comprehensive coverage of every policy
• A to Z listing of policies, unless users are trained otherwise (in many instances, users receive extensive training in how to use a policies and procedures manual)
• A brief description of the policy, who is affected by, or eligible for, the policy.
• Other requirements and conditions for applying the policy
• Instructions for administering (or, in the case of a benefit, applying)
• Forms to complete (almost every policy results in a form that people have to fill out)
• Samples of completed forms
• Ramifications of incorrectly following the policy

In addition, online policies and procedures manuals are often linked to employee databases, electronic forms, and electronic mail. This means that, as soon as users read about a policy, they can immediately complete any forms. When completing the form, the system already has access to information about the employee and can, at the least, automatically complete information identifying the person and, at the most, assess--to some extent--eligibility. Finally, when the user completes the form, the system can automatically transmit it to the appropriate administrator. For example, suppose a user is completing a request for reimbursement of travel expenses:

1. The system automatically completes the parts of the form with the user’s name, address, employee number, and manager’s name.
2. When the employee fills in the expenses, the system compares actual expenses with the company’s allowable limits and identifies those expenses that exceed the limits.
3. The employee adds explanations for the additional costs.
4. When the employee completes the reimbursement form, the system automatically transmits it to the manager for approval.

To find information in a policies and procedures manual, users need the same types of tools as provided in a reference. These include:

• For references with several printed volumes, the spine of the reference to make sure they are consulting the one that is likely to contain the entry. (For references with several online disks, users would check the disk label.)
• Running headers and footers to locate the likely location of the article. As part of the running header or footer, users expect to see the name of the article described on the page or screen. For example:

vacation - 188

• Headings to locate topics of interest once users have located the page of interest
• Subheadings to locate particular aspects of the discussion

Unlike references, however, most policies and procedures manuals also have:

• Comprehensive table of contents
• Index

because some users consult a policies and procedures manual as they would consult a user’s guide or other how-to communication product.

Users expect the writing style of policies and procedures manuals to be direct. They expect communicators to write the procedures part as they would write the procedures in a user’s guide. Because users with a wide range of education and experience use the same policies and procedures manual, and because users usually want the information as quickly as possible, they expect the manual to be written in plain language. In some cases, especially in policies and procedures regarding insurance, the law requires that you write the communication product in language that can be understood by people with a limited reading level. (The exact level varies among locations. Some require a seventh grade reading level, others a fifth grade reading level, and others a fourth. )

Top

Technical Communication Products that Share "Basic" Scientific and Technical Information

Basic scientific and technical information refers to the results of laboratory and field studies and scientific and technical concepts. Sharing this information from one part of the scientific and technical community to another has always served as a mainstay of technical communicators’ work. Scientific and technical information products commonly designed and developed by technical communicators include:

• Technical reports
• Articles for scientific, technical, and professional journals

Technical Report: A technical report is a report of the results of a laboratory or field study, or the results of other types of library or survey research, often conducted at the request of a client. Technical reports are primarily used in these ways:

• By the clients who requested them. Clients, and their representatives, use the information to make decisions. Some technical reports provide conclusions, that clients use to assess their current situation and determine a future course of action. Other technical reports provide recommendations, which suggest how clients should proceed in their work.
• By other scientists and technical experts, who use the information in the report as background material for future research.

Users expect the following material in a technical report:

• Executive summary, which is primarily intended for the executive sponsoring the report, and summarizes the report in such a way that the executive need not read further. Others might also read the executive summary to determine whether they need to read the body of the report.
• The following sections (in the order listed):
1. Purpose, which explains the purpose of the report, such as the reason the client commissioned the report or the research problem that the scientist tried to solve
2. Literature review, which presents previous research on the topic
3. Methodology, which explains how the scientists or experts performed the research. Others use this information to assess the credibility of the results.
4. Results, which provide the results that the scientists or experts received from their study.
5. Conclusions, which describe the patterns suggested by the results.
• In many instances, users also expect:
• Recommendations, which suggests how readers should proceed, based on the conclusions (make sure that your users expect recommendations before you provide them; some users resent your suggesting them, others welcome the ideas)
• Review of previous work in this area, also called a review of the literature (especially expected in academic work)
• Appendixes with related, though ancillary, data

Although users expect the same types of information in technical reports about topics in the social sciences, they are more flexible about the order in which you present the information.

To find information in a technical report, users consult:

• Executive summary
• Table of contents
• Lists of tables and Table of Figures, which list all of the tables and figures in the report so that users who are already familiar with the report can proceed directly to a listing of data that they need
• Running headers and footers
• Headings and subheadings
• Index (for reports over 40 or 50 pages)

For reports about business topics and the physical sciences, users typically expect an "objective" writing style, using the third person. Because most of the users have strong technical backgrounds, communicators can use technical terminology but should define terms that are unique to the study and that users might not have encountered before. For reports about topics in the social sciences, users expect a more relaxed style, and expect reports written in the first or second person.

Article: An article is a short, self-contained piece describing a topic. For example, an article might describe a recent study in a technical field, the limitation of a certain scientific theory, or advanced tips and techniques for using a certain type of software. Articles are published in:

• Scientific and technical journals, which are juried publications in which a panel, or jury, of group of experienced scientists and technical professionals, approves each article published. The editor of the journal removes the author’s name before submitting the article to the jury so that personal relationships do not enter the decision to publish.
• Professional and trade journals, which are edited by a team of professional editors, who choose the editorial content

Users consult articles to:

• Keep up with the latest trends in their field. Generally, such users subscribe to a journal, identify the articles of interest to them when they receive a new issue, and read them as soon as possible. Some users might read the issue in its entirety.
• Prepare for a research project. Generally, users consult a bibliography to identify articles of interest, then go to the sources and read those articles. Users often consult these articles years after their original publication.
• Study about a particular field. Generally, users are students in a class and the articles, considered by the instructor to be pivotal for one reason or another, are assigned as readings. Users might read these articles, too, years after their original publication.

The type of information users expect to find in an article varies, depending on the type of article.

• In a research article, users expect to see the same information they would find in a technical report, as well as a recommendation for further research and applications to other disciplines.
• In an article about theory, useres expect to see a definition of the theory, a description of its applications, and an explanation of its limitations.
• In a profesional article, users expect "how-to" information, which gives them "10 tips for using word processing" or "5 principles of page design."

In addition, users expect to find information that is related to the article in a "sidebar," a short article that is usually placed in a box within or immediately following the article. For example, a sidebar for an article with tips on using voice mail might describe the different types of voice mail systems available.

To find information within an article, users consult:

• Subheads
• Tables
• Illustrations
• Charts

li>Lists

The writing style that users expect with an article varies by the publication. In scientific and technical publications, users expect the same type of style they might expect in a technical report. In contrast, in professional journals, users expect a direct, second-person style, and they expect informatio to be presented succinctly and in practical, relevant terms.

Top

Technical Communication Products that Market Products and Services

In recent years, organizations have learned that, before users will read "how" to use technical products, services, and policies, and "what" scientific and technical research results and theories are, they must first sell them on the value of these products, services, and policies, or on the results and theories. The role of marketing communications products in the repertoire of technical communicators has therefore grown. Marketing communications products commonly designed and developed by technical communicators include:

• Proposals (which have always been a staple of technical communicators’ work)
• Catalogs (which ahve also always been a staple of technical communicators’ work)
• Brochures
• Newsletters

Proposal: A proposal is a communication product markets services by formally requesting that one organization choose the organization that wrote the proposal as a supplier of products or services. The proposal explains how the authors intend to meet the potential customers’ needs, why the authors are the most appropriate choice for the job, and provide background on the authors to build trust in them.

"Any company that must seek out and win contracts depends on effective proposals for its very survival" notes Butler (cited in Hamilton, 1996). Companies that must seek out and win contracts include large government contractors, such as defense firms seeking contracts to build new surveillance systems, aerospace manufacturers seeking contracts to build space craft, paper manufacturers seeking contracts for large quantities of computer paper (perhaps a year’s worth) and engineering firms seeking to contracts clean up hazardous waste sites. Other companies that must seek out and win contracts are computer suppliers seeking contracts to supply all of an organization’s computers and technical communication firms seeking contrats to develop technical communication products.

In all cases, you can expect several people within a customer’s organization to review a proposal before accepting it. The reviewers vary, but likely include at least one member of the technical staff, who considers the technical merit of the proposal, a purchasing agent, who considers the price and the terms and conditions of the sale, and an executive, who makes the ultimate decision based on input from otheres.

Some proposals range are extremely formal. For example, a government agency or large corporation would issue a request for proposals (RFP) from companies seeking to supply products or services. The RFP contains specifications for the product or service, and a list of questions and issues that companies seeking the contract must address in their proposals.

In contrast, other proposals are extremely informal. For example, a client agrees to use you to develop a communication product, but asks you to formally document your proposal, describing the services you intend to provide, the schedule you intend to follow, and the price you intend to charge.

Users expect the following material in a proposal:

• Executive summary
• Description of organization seeking the contract: who it is, the types of products and services it provides, the types of clients served, the names of references, descriptions of previous projects and, in the case of services such as consulting and technical communicationservices, descriptions of the people who will be working with the client
• Description of specific services to be rendered for the customer, including a detailed description of product or services (including product specifications, if requested by the client) and an explanation of how these product and services uniquely meet the customers’ needs
• Assurances of quality, such as a description of quality control measures
• Cost of products or services, broken down into component costs (for example, a proposal for technical communication services would not simply list the price of developing a technical communicatoin product but would list the costs of the technical communicator, of the editor, of printing, and other costs involved in producing a communication product)

When a customer provides an RFP, the customer usually tells you specifically which information to cover in the proposal and the order in which to present it.

To find information in a proposal, users consult:

• Table of contents
• Executive summary
• Running headers and footers
• Headings and subheadings
• Charts and tables
• Product illustrations (if appropriate)
• Index

As an added touch, many organizations use the logo of the customer for whom the proposal is being prepared within the proposal.

Because proposals need to convince potential customers to hire your client, the writing style for proposals is persuasive. The proposal should be no more technical than necessary; if the reviewers are anticipated to have strong technical backgrounds, you might make the proposal more technical than if the reviewers do not have a strong technical background in the nature of the product or service.

One unique aspect of writing proposals is that they are written in teams and on extremely tight deadlines. Organizations might prepare a 1000-page proposal in 30 to 45 days. To do so efficiently and effectively, organizations use several strategies:

• Reuse information from previous proposals, especially information about the company and its previous clients. Sometimes, the organization reuses the information as-is; in other instances, the organization might need to revise the information to suit the needs of the potential customer.
• Assign different people to write different parts of the proposal.

Rather than writing all of the material, technical communicators often take the material from the various sources and edit it so it appears to the potential customer to have been written by a single party.

Marketing Brochure: A marketing brochure is a technical communication product that describes a product or service so that users might consider purchasing or leasing it. Users consult brochures for two primary reasons:

• To get more information about a product or service, to determine whether or not they would like to consider purchasing or leasing it
• As a leave-behind, to recall a product or service that they saw before

Although brochure have, in the past, been printed on glossy paper and lavished with color and other items to attract users’ attention, they are increasingly presented online, as home pages on the World Wide Web or as diskettes or CDs distributed to users.

Users expect the following material in a brochure:

• Name of product or service
• A description of the ways it benefits the potential user
• List of key product features (for high tech products, a list of technical specifications, too)
• Instructions for getting more information and ordering
• Terms and conditions of sale, such as whether or not the price includes technical support

In addition, brochures might also contain the price, if the product is sold at the same price in all places (which many are not). Online brochures might also include a product demonstration, especially if the brochure describes a software product.

To find information in a marketing brochure, users consult charts, headings, icons, and visuals.

The writing style of marketing brochures is persuasive and direct, and contains no more technical terminology than users already know. If a new technical term must be used, it should be defined. Similarly, if potential customers typically use certain buzzwords in their work, the brochure should include them as a means of gaining rapport with users. Technical communicators also make use of catchy phrases and visuals and visual cues, such as colors and bold lines, to attract users’ attention to the brochure. Because brochures represent one of the key means of reaching potential customers, they must attract users’ attention.

Catalog: A catalog is a printed or online publication that describes the products offered by a company and from which customers either consider a purchase or place orders. One type of catalog typically produced by technical communicators is a parts catalog, that presents spare parts for machines and high technology products.

Users expect the following material in a catalog:

• Product information, including:
  • Picture of the product
  • Description of key features
  • Dimensions
  • Sizes available (if more than one)
  • Colors available
  • Capacity
  • Price
  • Order number
• Instructions for placing an order, including order forms, fax and telephone numbers, e-mail address, and shipping information
• Terms and conditions of sale

If users have limited or no familarity with the organization, a catalog should also provide some background on the company to build credibility with consumers. Similarly, if the organization has retail locations, the catalog should provide list of them.

To find information in a catalog, users consult:

• Table of contents, which is often placed on the front cover to quickly direct users to products of interest
• Headings and subheadings so, when users reach the pages or screens of interest, they can easily find the products of interest
• Bleed tabs
• Color coding, so users can easily scan for products of interest by looking for pages with the appropriate color
• Running headers and footers, to help users determine where they are in the catalog
• Index, to direct users to particular parts of the catalog

The writing style for a catalog is tight, using as few words as possible to convey ideas. Communicators often use phrases rather than sentences, and a terse style. For consumer products, technical communicators sometimes use a persuasive tone to develop interest in products among users.

Newsletter: A newsletter is a communication product that contains a collection of articles and provides ongoing communication with a target group. For example, a product newsletter provides ongoing contact with the customers who have already purchased a product. An employee newsletter provides ongoing contact with the employees in a department or within an entire organization.

Users usually receive newsletters when the receive their mail; they might skim the newsletter at that time and, if they any interesting articles, read those at a later time.

The type of material that users expect in a newsletter varies, depending on the nature of the newsletter. A newsletter whose primary purpose is maintaining contact with existing customers might suggest additional ways of using existing products, highlights of new products and, if customers have contact with the staff, profiles of people whom customers might deal with. In contrast, a newsletter that is intended to provide the users supported by a technical suppport group might provide answers to them most common questions, tell users about new software available to them and provide profiles of the members of the technical support team.

To find information in a newsletter, users consult:

• Table of contents, which is usually published on the first page or last page (so users can easily see it), called "Inside" and gives brief previews of articles
• Headings
• Charts and tables

In addtion, some users rely on the regular placement of certain information in each issue of a newsletter. For example, one financial newsletter always publishes a table with current exchange rates on the next to last page. Users who want this information immediately turn to it.

The writing style of newsletter articles varies, depending on the purpose of the article. In general, technical communicators use a persuasive, informative style and write in the second person.

Beginning of this section

Technical Communication Products that Train Users

As organizations have learned that they must "market" products, services, and policies before users will read "how" to use them and "what" they are, organizations have also learned that merely providing information on how and what does not provide users with sufficient access to information; in many cases, organizations need to train users in how to use information and apply concepts. The role of training materials in the repertoire of technical communicators has therefore grown similarly to the role of marketing communications products. Training materials commonly designed and developed by technical communicators include:

• Tutorial
• Job aid (also called quick reference)

Tutorial: A tutorial is a lesson, or series of lessons, that are intended to develop a skill that users can immediately use. The tutorial might be online, it might be contained in a printed workbook, or it might be presented in a class.

Users take tutorials for a variety of reasons. In some instances, they’re told to. For example, employees may be required to take training about a new company policy or to fulfill a legal requirement (the reason for most safety training). In some instances, users take tutorials to know how to perform a task in a more instructive way than might be found in a procedures manual or online help. Examples include users consulting commercial books about software, such as Windows for Dummies, to learn how to backup systems and tutorials provided with spreadsheets that teach users how to use formulas. In still other instances, users take tutorials to learn about an entire subject, such as tutorials on CD-ROM about career management and workbooks about preparing taxes.

Users expect the following material in a tutorial:

1. At the beginning of a lesson, users expect:
• A brief description of the purpose of the lesson (about 30 to 50 words)
• A list of skills users will develop (take them directly from your content objectives)
• Prerequisite skills and knowledge
• Length of time needed for the lesson, so they can decide whether they have sufficient time now or need take the lesson later
2. In the lesson, users expect:
• Clear explanations of concepts and procedures
• Practical examples of the skills
• Opportunities to apply the new skills through
• Active involvement in the learning process, through exercises, simulations, questions, and other techniques
3. At the end of the lesson, users expect:
• Descriptive summary, that repeats the main points they should remember
• Glossary, which defines new technical terms presented in the tutorial

To find information in a tutorial, users consult:

• Table of contents (or, for online tutorials, the menu of lessons)
• Running headers and footers
• Forward and backward buttons to reread informtio they already seen.

In some intances, users prefer that you recommend a sequence through the tutorial and do not give them alternate methods of going through it. In other instances, users prefer to have total control over their movement through the tutorial.

The writing style for tutorials is persuasive, because the tutorial needs to motivate users to take an interest in the subject matter, as well as clear and involving, in which users understand the material presented and how it relates to them, and feel actively involved in the lesson. Finally, the style should be polite, though direct, like that of a good teacher with a student.

Job Aid (Quick Reference): A job aid is a technical communication product intended to give users a brief refresher of a training module on the job. Job aids also go by the name quick references.

Users typically consult a job aid in the middle of a task, when they need a quick reminder about a key point. They might locate the job aid or, in many instances, find the job aid already available. A Post-It--note with the name of a commonly used command and placed on the side of a computer screen is an example of a job aid. An audiotape that summarizes the key points of a day-long training seminar in 12 minutes is another example of a job aid. A laminated card with a list of commonly used commands is yet another example of a job aid.

Users expect a job aid to contain cryptic, but meaningful, reminders. The writing style is terse, almost to the point of seeming incomplete. The physical design of job aids is usually imaginative, ranging from pocket-size cards that users can carry with them anywhere to mouse pads that have key messages written on them and that users can see any time they sit by their computer.

Top

Issues in Choosing a Type of Communication Product

Choosing a type of communication product involves balancing the needs of users with the needs of the client.

The Needs of Users

If effective communication design provides intellectual, physical, and emotional access to information, then you should consider each of these types of access when choosing a type of communication product. When choosing a type of communication product, consider each of these issues.

Intellectual Access: Consider the type of information users need and expect. If users expect a procedure, for example, you should consider types of communication products in which users expect procedures, such as a user’s guide or tutorial. If users expect comprehensive coverage, choose a type of communication product in which useres expect comprehensive coverage, such as a reference or policies and procedures manual.

Physical Access: Consider the amount of information that users can handle. If you’re trying to feed "nibblers" with a "hungry heiffer" diet of information, the abundance of information will overload users and ultimately serve as an impediment to their understanding. Similarly, consider the logistics of the workspace of users. For example, if users just need a quick reminder of information and have a small workspace in which to read, you might choose to provide a job aid rather than a larger user’s guide, which users might have difficulty reading in their confined work space.

Emotional Access: Consider the users’ emotions at the time they read the information. If, for example,users are novices and nervous working with the material, you might choose to provide a tutorial, which gives users an opportunity to view examples and and try exercises before performing a task, rather than a user’s guide, which just presents the instructions and lets users try them. Conversly, if users are experienced with the content and can zip through an entire procedure with little or no instruction, you do not need to provide detailed, step-by-step instructions.

Just as importantly, consider what users expect. If users are expecting to receive a printed user’s guide and you choose, instead, to provide them with online help, you will need to address this difference in expectation if users are going to feel satisfied with the help. For example, when one major software publisher dropped its user’s guide and replaced it with online help, many users felt that the publisher failed to provide them with adequate support in performing the intended tasks.

The Needs of Clients

Consider, again, the instance in which the software publisher chose to provide users with online help rather than a user’s guide. Admittedly, some users were disappointed that they did not receive a user’s guide. Why, then, would the publisher choose to purposely disappoint some customers.

In this particular instance, the client also had business needs that needed to be met. These needs included:

• Reducing printing costs; distributing diskettes and CDs is less costly to the publisher than distributing printed guides
• Promoting among users and increased dependence on software and an increased acceptance of receiving information online, as a means of generating demand for future online products

The publisher also recognized that, although a small percentage of users might not like the change in approach, the majority would and the publisher it was willing to take the risk associated with publishing the user’s guide as online help.

Although users’needs are usually the first issue considered when you choose a type of communication product, you must also consider the client’s business goals when making the final choice. In such instances, the solution is not a "clean" one but, rather, the best compromise you can reach given the requirements of the situation.

In addition to considering clients’ business goals, also consider their businesss constraints:

• The budget available to them; certain types of communication products are less costly to produce than others; when given a choice among types, choose the one that better meets the client’s budgets
• The estimated development time for the communication product; certain types of communication products take more time to develop than others; when given a choice among types, choose the one more likely to be completed by the client’s deadline

The Expectations of Users and Clients

After you choose a type of communication product, take a few moments and list the expectations that people bring to that type of product. You might also interview your client to determine what expectations they have. For example, suppose that you have chosen to recommend a newsletter as a means of presenting advanced tips and techniques to users of OneCare. Identify the expectations that users have of a newsletter:

• Content they could not figure out on their own, such as
  • Answers to common questions
  • Tips on using function that are not readily visible or intuitive from the screens
  • Examples of macros written by programs and routines written by other users
• An "Inside" box on the front or back page directing users to topics of interest
• Headings
• Regular placement of certain information in each issue of a newsletter

Compare these expectations with those of the outline you previously developed. Does the type of material that you intend to cover match type of the material that users are expecting? If you are not meeting the minimum expectations, then users will not likely find value in the newsletter and might ignore it. If you are providing all of the material that users expect--and then some--anticipate how will users respond to the additional material. Will they find value in it, will it overwhelm them, or will they find it to be "overkill?" In both cases, you should probably adjust your outline to meet the expectations of users.

Furthermore, compare the expectations of users with the expectations of your clients. For example, your client might believe that a newsletter should have a picture of the Director of Computing Services and a message written to users from this person. Your client might also be reluctant to give examples of macros, for fear that they users might have difficulty trying them. In the case of the message, you will exceed user’s expectations but the additional information might be perceived as excess by user. In the case of the examples, you will fail to meet users expectations and that puts the success of the entire communication vehicle at risk. You will need to provide some information that compensates.

Top

Summary

The 13 most common types of technical communication products:

• Those that explain products, services, and policies, including user’s guides, help, service guides, references, and policies and procedures manuals
• Those that share "basic" scientific and technical information, including technical reports and articles
• Those that market products and services, including proposals, catalogs, brochures, and newsletters
• Those that train users, including tutorials and job aids (quick references)

It also presented issues for choosing a type of communication product:

• The needs of users, especially their needs for intellectual, physical, and emotional access
• The needs of clients, especially their business goals, and constraints

Top

models | processes | techniques | resources on i.d. business and management | home

(c) Copyright. 1999, 2000, 2001, 2002. Saul Carliner. All rights reserved.