Technical Writers’ Companion

The first example shows an excerpt from a user manual for a DVD recorder. Users don’t want to know which connectors, controls, and other items are included in your product. Users want to know how to accomplish some specific task.

Nein:

Ja:

The next example shows an excerpt from a user manual for a program that manages client information.

Nein:

Ja:

A user-centered, goal-based structure is one of the key factors for successful user assistance and user-friendly documentation.

More than 90% of users don’t care about how a product works. Most users don’t read any documentation before they begin using the product.

▪Users go to the documentation only when they feel stuck.

▪Users stay in the documentation only until they feel unstuck.

Imagine the following, typical scenario:

A user is writing a letter and wants to add a picture. So the user’s goal is to insert this picture into the letter.

▪A goal-based document would provide a topic such as “Adding pictures to your documents,” which is exactly what the user will be looking for when skimming the table of contents.

▪A product-based document, on the contrary, would contain topics such as “The File Menu,” “The Edit Menu,” and “The Image Menu.” The user must then guess where the needed function could be hidden. In the worst case, the user must open and read several irrelevant topics before finding the needed information.

Help people to use your product; don’t describe the features of your product. Provide assistance—don’t provide documentation.

Anmerkung:
A goal-based structure can also be an effective instrument to market your product. Guess what’s more appealing when a potential client downloads a trial version of a program or a PDF manual before buying a product: a table of contents that lists all controls and menu items of the product, or a table of contents that reflects exactly what the potential client is aiming to do?

Often, users’ goals aren’t identical with the tasks that need to be performed to achieve these goals.

For example:

▪Your own goal is to enable users to use your product. Your task to achieve this goal is to write a manual (or some other form of user assistance).

▪A user’s goal may be to save paper when printing reports. However, the tasks that the user must perform to achieve this goal are different. For example, the user can change the printer settings so that two pages are printed onto one sheet of paper (task 1), or the user can enable double-sided printing (task 2).

When possible, use goals for headings rather than tasks because goals are what users are primarily looking for when browsing through your document. Users know what they want to achieve, but they don’t know which tasks may be involved. Only use tasks for headings if users need to perform more than one task to achieve a goal.

Often, the best solution is to set up one topic that reflects the goal, and then to add subtopics that reflect the tasks necessary to achieve this goal.

Example:

Goal-centered topic titles and structures are the optimal choice for procedural information, which usually accounts for most topics within a user manual or help system.

For conceptual information and for reference information, however, other structure models are often more appropriate (siehe auch Distinguish information types and Primary structure models). In this case, find topic titles that are in line with the chosen structure model.