Almost every product needs some sort of user manual. Simple products may need only a single page of instructions; complex products or software may need manuals than run into the hundreds of pages. In fact, many pieces of software come with manuals that are too cryptic to be followed and generate a demand for books that explain the products in a far more understandable way.
Know Your Audience
The more you know about the audience that will read the eventual user manual, the better. Build a profile of your readers. This profile will indicate the background knowledge readers are likely to have before picking up the user manual, the types of difficulties one might expect the readers to experience, and their likely preference for narrative or graphic instructions.
After developing a draft version of the user manual, show it to subjects who are likely to be genuinely interested in using the product and have no experience with it. Work with them to discover what they find satisfying and what they find difficult about the manual. Incorporate their feedback into the follow-on versions of the manual.
Understand the audience’s likely state of health, their age, education, etc. to assess the best approach for structuring the user manual.
Understand the Product
Writers needs to understand the products almost as well as the product developers. However, product developers often don’t have the skills to write user manuals. That means there has to be a very close working relationship between product development teams and their writers.
Development teams need to demonstrate their products to their writers to the point they are thoroughly familiar with them. Writers will use that knowledge to draft user manuals and review them with the development teams. The writers will sketch out the graphics that complement the narrative. Once they have drafts in place, the writers will review them with the development teams in detail and include feedback. This review process could easily call for several iterations until the user manuals are ratified as technically accurate.
With this in mind, the teams need to appoint one of their members to serve as the primary point of contact with the authors of the user manuals.
Analyze Each of the Tasks
The writer needs to identify each of the individual tasks the product can perform. These tasks include the assembly or set up of the product (batteries, assembly process, components, etc.) as well as the normal operation of the product for its intended purpose. A camp stove, for example, needs to be attached to a fuel source, the fuel level needs to be adjusted, and the flame needs to be lit.
In addition to the normal operation of the device, the manual needs to include troubleshooting advice. It needs to identify the sorts of things that normally can go wrong and the steps to be taken to correct the problems.
Align the User Manual with the Labels and Advertising
It’s quite likely the product already has a label or packaging and that the company has been advertising it for sale. In either case, the writer needs to ensure that the user manual is consistent with the label and advertising.
Determine the Layout of the User Manual
The Table of Contents (ToC) of the user manual provides the overarching framework for the user manual. This ToC will probably be written in terms of major and minor headings. The ToC allows the stakeholders to determine that the user manual will be comprehensive. It is also useful in helping to assign product specialists to work with the writer to prepare the content of the manual.
It is quite effective to design the manual using two columns per page. One column could have text and the other column would have bullet points, numbers, icons, photographs, etc. The manual could be primarily images with some explanatory text to elaborate on the images. On the other hand, the manual could be primarily narrative or text with the occasional graphic that would illustrate the messages in the narrative.
Another option is to structure the user manual around a flow chart.
The layout chosen should be aligned with the nature of the product and the learning style of the manual readers. In any event, the entire manual should follow a common style. Mixing styles is confusing.
Include Warnings at the Beginning of the Manual
These warnings should identify ways the product might be misused and the consequences of misuse. For example, it might be important to warn users to keep their hands dry when plugging in the device if there is a risk of shock or death otherwise.
Use industry standard graphics – such as a skull and cross bones – to warn of the risk of death. Use red text to highlight warnings that are particularly dangerous.
Describe the Product
The manual should include a photograph and/or a graphic showing the product. It should also include labels or names for all the knobs, switches, or attachable parts. If the product is a piece of software, the manual needs to identify all of the components of the user interface and a short description of each piece.
Include Setup Instructions
The manual needs to explain how to set up the product or install the software. If the product needs to be installed by trained personnel, then the manual needs to say so clearly.
The manual also needs to provide:
- A parts list
- Unpacking instructions
- Warnings related to setup
- Contact numbers in the event that the set up or installation does not go smoothly
Explain the Operation of the Product or Software
This is the main part of the user manual. This is the section that provides detailed, step-by-step instructions about how the device or software works. Quite likely, the manual will number the steps sequentially to help ensure that none of the steps is missing.
The description of the operation of the product should include both text and graphics – either photographs or diagrams. If possible, include web links to videos demonstrating the operation of the product.
Explain How to Store the Product
Some products must be stored within certain temperature or humidity ranges. Some products need the batteries removed for prolonged storage. Explain how the user should store the product when it is not in use.