User manual template, with a finished example chapter

What a user manual includes

Five parts, each answering one question the reader brings. The task part is most of the manual; the others stay short.

Around the five parts sits the front matter: a title, the product version and the manual version with a date, the contents, and notices. A notice is anything that loses data or money, or can hurt someone; it goes first and is repeated in the task where it happens.

Organise the tasks by what the user wants to do, not by menu or module. The Microsoft Writing Style Guide asks for headings that describe what the instructions help the reader do, in parallel form: "Void an invoice", "Export a report", not "Invoice actions" next to "Exporting".

Two standards cover the ground. ISO/IEC/IEEE 26514:2022 covers the development process for designers and developers of information for users of software. IEC/IEEE 82079-1:2019 sets principles and general requirements for instructions for use of products of all kinds.

User manual template

The template downloads without signup. It holds the front matter with a contents field, the five parts, one task block marked to copy once per goal, and an optional appendix for a physical product.

• Title table: product and version, manual version and date, who it is written for, one owner.
• Important notices: data or money at risk; delete the part if there is none.
• Overview: three short headings. Write them last.
• Setup: requirements, a role table, the first sign-in as numbered steps.
• Chapter and task block: a goal title, when to do it, Before you start, Steps, Result, If it goes wrong. Copy the block once per goal.
• Troubleshooting, Glossary, Change list: tables, one row per error, term or release.
• Appendix A: intended use, safety warnings, model and serial number, specifications, maintenance, disposal, support and warranty. Optional; delete it for software.

In Word, parts and chapters use the Heading 1 style, tasks Heading 2 and the parts of a task Heading 3. The contents is already a field built from those styles, as Word's References > Table of Contents would make it; after editing headings, right-click it and choose Update Field (Microsoft Support). Keep the styles when pasting text in: paste as text only, then apply the heading style.

The German page has the same files in German.

Example chapter: Invoices

The example is chapter 4 of a user manual for Ledgerly, written for the accounts team at Northwind, a made-up company. Ledgerly is a demo accounting app built for these guides; the screenshots are real recordings of it, one marker per screenshot, customer names blurred. The chapter has one task section, a troubleshooting entry and its glossary lines. It reuses the task, the recording and the screenshots of Work instructions, which writes the same task as a work instruction for Northwind's finance team; here it is a manual section for the product's users. Download the chapter (PDF, 2 pages).

Its task section, as the manual prints it:

Goal title

4.1 Void an unpaid invoice

When

An invoice was sent in error and the customer has not paid it.

Before you start

The Ledgerly Finance role and the invoice number. The status must be Awaiting payment or Overdue; a Paid invoice cannot be voided.

Steps

1. On the Invoices page, in Search invoices, type the invoice number, for example 10427. One row is left.

   

2. Click the row #10427 and check that its status is not Paid.
3. Click Actions. A menu opens.
4. Choose Void invoice.

   

5. Check the notice above the tabs and the status in the row.

   

Result

The notice "Invoice #10427 voided"; the status reads Void, struck through. The invoice keeps its number.

If it goes wrong

A red notice "… is Paid and cannot be voided": see the troubleshooting entry below.

Steps 2 and 3 have no screenshot: the row and the Actions button are already in the step 1 picture.

The troubleshooting entry comes from the real error met while recording, on invoice 10428:

Glossary lines the chapter added:

• Awaiting payment: sent, not paid, not yet due. Can be voided.
• Overdue: sent, not paid, past its due date. Can be voided.
• Paid: the payment has arrived. Cannot be voided; refunded instead.
• Void: cancelled. Keeps its number and stays in the list, struck through.

Anatomy of a task section

Finish on the result, not on the last click. Wording and step length are covered in Step-by-step instructions; cropping, marking and blurring in Screenshots for guides.

How to write a user manual

1. List the users and their goals. Support tickets and onboarding questions are the source: they are in the users' words.
2. Turn each goal into a task section title, verb first, and group the titles into chapters by area of work.
3. Do each task once in the real product and capture it step by step, with test data.
4. Write the steps from the captures. Blur or crop out personal data before anything is shared.
5. Write setup from what a new account actually needed while capturing.
6. Fill troubleshooting from the real errors met while capturing, then from tickets.
7. Collect the glossary from the interface labels the steps use.
8. Write the overview last. Only then is it known what the manual covers and leaves out.
9. Test with someone who has never used the product. Watch where they stop, and fix that step.

Steps 3 and 4 take most of the time. A recorder that turns each click into a numbered step with a screenshot shortens them; with the built-in screenshot keys (Win+Shift+S, Cmd+Shift+4) the same job is one capture and one crop per step. For a long settings page, a full-page screenshot can replace several.

Software manual or product manual

The skeleton is the same. What changes is the front and the back.

• Software: system requirements, accounts, roles and permissions, and the version covered. Screenshots go stale when the interface changes, so the version line matters.
• Physical product: what is in the box and installation in setup, safety warnings in the notices and in the task where the hazard occurs, and a product appendix at the back.

For a physical product, IEC/IEEE 82079-1:2019 sets out what the instructions for use contain in its clause 7, Content of information for use. Its sub-clauses include identification of the product and of the supplier (7.2), the product description and specifications (7.8), maintenance (7.10.10), disassembly, recycling and disposal (7.10.14) and safety-related information, with safety notes and warning messages (7.11). The template's optional Appendix A collects these as one table:

• Intended use: what the product is for, and uses to avoid.
• Safety warnings: the hazard, what can happen, how to avoid it.
• Model and serial number: where they are printed on the product.
• Specifications: power, dimensions, weight, operating conditions.
• Maintenance: what the user cleans, checks or replaces, and how often.
• Disposal: how to dispose of or recycle the product and its batteries.
• Support and warranty: the supplier's name, address and contact, and the warranty terms.

The clause numbers and titles above come from the standard's contents page; what each clause requires in detail is in the standard itself.

A "personal user manual" (a "how to work with me" page about a colleague) is a different document and is not covered here.

User manual, SOP, work instruction, training manual or job aid

A user manual's task sections are written at the work-instruction level: one task, step by step at the screen. The same capture can serve a work instruction and a manual section; what differs is the reader and the frame around them. An SOP sits a level above: the written procedure, who does what, when and in which order. Where each document sits is in Process documentation; a manual for staff in training is a training manual, and the one-page version of a task is a job aid.

Keeping the manual current

• Versions on the title page: the manual version and the product version, with a date, and a dated change list at the end.
• Recapture, do not patch: when the interface changes, redo the affected task sections from a new capture rather than editing old screenshots.
• One owner per chapter: the person who owns that area of the product, named in the chapter header.

Sources