Skip to content


How to Write a User Guide


 Powered by Max Banner Ads 

©  Ugur Akinci

An excellent and affordable entry-level Online Course: Technical Writing 101

A user guide consists of the following components:

  • Front Cover
  • Front Matter
  • Table of Contents
  • List of Figures
  • List of Tables
  • Introduction
  • Chapter 1
  • Chapter 2

  • Chapter N
  • Appendix 1
  • Appendix 2

  • Appendix N
  • Glossary
  • Index
  • Back Cover

Not all of these components are always present in every user guide. Some user manuals for example will not have a Glossary or a List of Figures. It just depends the kind of guide you are writing and its size and complexity.

FRONT COVER should be simple enough not to confuse the reader but still detailed enough to communicate the most important basic information about the product or software. A front cover should not have a page number.

At a minimum, a goof Front Cover should have the NAME of the product or software in question; VERSION number; DATE of the document; COMPANY LOGO and COMPANY INFORMATION.

Click here for a more detailed explanation of how to design a great front cover for a technical document.

FRONT MATTER, just like the Front Cover, also does not have a page number and it’s the page coming right after the Front Cover. It includes copyright information, company web site, and any legal disclaimers, warnings or disclosures that might be appropriate. If the document has an ISBN number or any other publication identification information that belongs to the Front Matter as well.

TABLE OF CONTENTS should list all chapters and sub-chapters with page numbers, not more than 3-levels deep. Human attention wavers at anything deeper than 3 levels. (This is true for the INDEX as well.) Most text editors like Microsoft Word or Adobe FrameMaker have their built-in TOC generators that pick up paragraph styles and convert them into a TOC. Every technical guide should have a TOC unless it’s a 3 or 4 page short document. Anything over 20 pages and/or 10 chapters/sections definitely deserves a TOC.

LIST of FIGURES and TABLES. If you have just a few figures and tables and a short manual you would not need to have a list. However, if you have lots of figures and tables (say over 15 or 20) you should definitely have a list and list all figures and tables with their CAPTIONS (or TITLES) and PAGE NUMBERS. That way your readers can find the figures and tables they want easily.

INTRODUCTION is important since this is where you explain WHAT the document is all about and for which AUDIENCE it is written. Here you can also give a thumbnail sketch of what’s ahead, including a short one-sentence summary of chapters (best presented in a table format). An explanation of special terms, icons, abbreviations, acronyms and other special information that the user should know about to make sense of the manual… they all belong here. CONTACT INFORMATION (Company Name, Address, telephones, web and email information) can be included here as well although some writers prefer to include that in the FRONT MATTER and BACK COVER.

CHAPTERS should cover distinct groups of information devoted to one topic. You’d be the best judge of which information goes into what chapter. Chapters should closely follow the Documentation Plan, which in turn should be prepared in beginning of a technical writing project and approved by the management or the client.

Click here for a more detailed explanation of how to write a chapter for a technical document.

APPENDIX is for the kind of information that the read should be aware of but either does not fit in smoothly with the flow of the main chapters in the manual or consists of reference information. For example, the WIRE GAUGE information in an electronics manual, or all the HEXADECIMAL COLOR CODES in a manual about web design would make a useful appendix.

GLOSSARY is a life-saver for a lot of readers if the manual if full of technical terms that are not widely known. It’s good practice to assume that your readers might not be familiar with your terms, acronyms and abbreviations and list them in a tabular form and in alphabetical order in a Glossary.

INDEX is a very important part of any technical document, especially if you are writing something that is hundreds of pages long (which is not unusual in technical communications). Creating an index (or “indexing” as it’s sometimes also referred to) is such a specialized function that there are technical communicators professionally known as Indexers who do nothing but indexing on a full-time basis. They even have their own associations. There are a few useful rules of indexing that you should apply every time you generate an index. Click here to learn more about this crucial task that needs to be performed correctly.

BACK COVER should be elementary and contain only absolutely necessary information. That includes the name, address and logo of the company; the title, version, and document number of the manual; any copyright information, etc. Keep the back cover as simple as you can.

Share

6 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Marie-Louise Flacke says

    Who reads the introduction? Are you sure the end-user is interested in the introduction?

    • admin says

      Marie-Louise, you’ve raised an interesting and excellent question. “Is the end-user interested in Introduction?” My answer is: it depends… on the end-user and the context.

      The list provided above still assumes “codex” (The Book) as the main format. However we all know that more and more in technical communication “topic” based “structured authoring” is replacing the traditional book-style documentation. And, you’re right, in that kind of environment Introduction does not make sense and no one reads it because they do not use the document in a linear fashion. They just jump to whatever topic they’re interested in to save time and energy.

      However, the behavior described above is that of an intermediate or advanced user. A totally novice user may prefer a more incremental and gradual approach where one would start reading a manual from page 1 and proceed accordingly. In that context an Introduction of course makes sense. And for the sake of completion I listed it in the above article.

      There’s one other reason why Introduction might be necessary — legal reasons. If certain crucial “system requirements” or other critical operational information are not included in the Introduction (or similar) chapter there may be a law suit if and when anything goes wrong due to lack of such information. So by including an Introduction (or Front Matter, Preface, etc.) the author may protect herself from such an eventuality. I recommend all technical communicators to consult their clients and the legal departments of their companies to understand the legal implications of including (or excluding) such information.

      Again, thanks for the excellent question! Ugur

  2. Marie-Louise Flacke says

    System requirements in the introduction?
    Why not a section with a title like:
    - “System requirements”
    - “Preparing the installation”
    - “Getting started”
    etc.
    ?

    • admin says

      Yes, certainly, you can do that too. There is some flexibility about what you can include in the Introduction. If you believe that system requirements deserve a section (or chapter?) of their own, you can create a separate section/chapter as well. Same goes for the other two topics you’ve mentioned. That’s a personal judgment call you need to make as a writer unless your client- or corporate-guidelines dictate otherwise.

  3. Bharat says

    Hey,

    It was nice to read about the article like technical writing and Function Spec

    Bharat

    • admin says

      Bharat, thanks! Glad to help. Ugur



Some HTML is OK

or, reply to this post via trackback.