Nintr

1. User Guide Standards Technical Writing
2. Writing Technical Manual Examples
3. Technical Manual Writing Software
4. User Guides Manuals And Technical Writing: A Guide To Professional English Pdf
5. Technical Writing Instruction Manual

Many companies these days lack human resources. Especially for technical writing. Manuals and user guides drafted by engineers – is both inefficient and in most cases really not the best approach towards dealing with technical communication within a company. Apr 28, 2018  Technical documentation is a set of documents used in engineering, manufacturing and utilizing objects of technology such as buildings, products, software, and hardware. In a broader perspective, technical documentation encompasses all the documen. User guides and user manuals $35/hr Starting at $70 fantastic clear and crips graphical technical user guides and manuals. Based on CAD images. Animations or fixed images rendered photorealistic or in technical drawing style.

In a previous article, I went over 14 examples of documentation mistakes you might be making. Today, I'm going to show you 10 examples of what makes great end user documentation.

I should clarify that end user documentation does not serve the same purpose as technical documentation, so you shouldn't write them the same way. Technical documentation is meant to teach somebody everything there is to know about a subject, whereas end user documentation is meant to just show somebody the necessary steps to accomplish a task and answer 'How to...' questions.

The examples I show are examples of what makes great end user documentation.

1 - Write great titles

User Guide Standards Technical Writing

1. Layout and order information: here you will find guidelines on style issues, e.g., headings, bullets, punctuation and capitalization. Typical grammar and vocabulary mistakes: this section is divided alphabetically and covers grammatical and vocabulary issues that are typical of user manuals. User Guides, Manuals, and Technical Writing.
2. This book is intended for anyone whose job involves writing formal documentation. It is aimed at non-native speakers of English, but should also be of use for native speakers who have no training in technical writing.Technical writing is a skill that you can learn and this book outlines some simple.
3. Advanced Instruments, Motorola Mobility, Eaton, The Home Depot and many other companies choose to work with us when developing their companies’ manuals and guides. When you trust your user manual and guide needs to us, you know we are providing documentation that improves the user experience and the solutions to your documentation needs.

Great end user documentation consists of titles that are specific, and often in the form of performing a task. This not only makes it easier for your end users to find what they are looking for, but it helps you write better articles.

For example, think about how much time it would take to write an article titled 'Contacts' - you wouldn't know where to start. So you create an outline of all the 'Contacts' topics you can think of, take screenshots of the Contacts object, explain all of the menu options, and write a history of the Contacts object - all useless to an end user who just wants to know how to create a partner contact in Salesforce. Instead of going right to the information they need, end users will have to sift through all of the other stuff to find an answer.

If each article has its own, great title, then your end users can quickly answer their own questions by performing a keyword search or by browsing through your table of contents.

HubSpot does a great job writing useful titles, and then demonstrating the workflow using pictures, text, and annotations. Their documentation is a great example of how to write end user/customer documentation.

Tip for writing great titles

To continue the example from above, instead of writing one big article titled 'Contacts' just write a dozen little articles that each answer one specific question:

1. What is a contact?
2. How do we use contacts?
3. How to create customer contacts
4. How to convert a lead into a contact
5. How to create partner contacts
6. How to create an account for a contact
7. How to merge duplicate contacts
8. How to import contacts from Outlook
9. How to import contacts from a CSV file
10. How to add contacts from Gmail using Cirrus
11. How to change the Contacts view
12. How to log a call with a contact

These are so much easier to write, and your end users will find them much more useful because they can quickly search for, and find, answers to their specific questions (end users need specifics). Plus, you can always combine a lot of little articles into a larger workflow and organize them into a chapter or a manual.

2 - Use annotated screenshots

The majority of end user documentation should have screenshots, and those screenshots should include some sort of annotation. Adding an arrow, a circle, or number sequences can make end user documentation completely dummy proof, and save end users from having to figure out what to do.

Even if it seems obvious to you where to click, including a few simple annotations will go a long way in removing confusion.

3 - Use video AND screenshots AND text

If you have the budget, the patience, and the time, you can do what Wistia does - create a video explanation, then include step-by-step instructions underneath the video.

This is a great way to do end user documentation. The video acts as a teacher to explain an overall process and provide some initial training. But after the initial training, end users don't need to watch the entire video again - they just need a quick reminder of what to do. The step-by-step instructions are great for the quick reminder.

4 - Include links to related articles

When you reference another action, product, workflow, or term, it always helps to include a link to the related article. Otherwise, end users waste time searching for what you just referenced.

5 - Easy to browse

if you only have 10-20 articles, then you don't really need to make them easy to browse. It's when you have over 20 or 30 articles that you really want to make a nice Table of Contents - especially if your documentation is online.

When your end users don't quite know what to search for, they can browse your documentation to find an answer. In this example, Metric Insights has organized their manuals into sections, and then each manual is broken up into chapters and articles.

6 - Easy to search

Google has spoiled everybody. When your end users know what they are looking for, they expect to be able to type in a keyword and find an answer. If your documentation isn't searchable, then it's not going to be used very often.

7 - Easy to find

Below is an example of the ScreenSteps integration with Salesforce. It provides links to articles based on which Salesforce tab is open so end users don't have to go very far to find relevant documentation. Plus, it has a keyword search feature so end users can type in their question and search your ScreenSteps documentation for an answer.

The faster end users can answer their own questions, the less time you'll have to spend answering them yourself or showing them where the answers are.

8 - Show the end result

Writing Technical Manual Examples

At the end of it all, what is the end user supposed to see? Here, Skuid does a nice job including a screenshot of the end result with a brief explanation to help end users determine whether everything was done correctly.

9 - Show the steps and substeps

Including step numbers makes it easy for end users to follow along and piece together what they are doing. You can also take advantage of sub-steps to make your documentation easier to follow.

10 - Unique URLs for each article

If you were to click on this URL - http://help.screensteps.com/m/salesforce/l/211489-add-contextual-help-and-search-in-salesforce you would be taken to the exact article you need to answer your question about how to create a campaign target list. This makes it really easy for you to respond to questions with links to your documentation. Otherwise, you have to say, 'Download this PDF, go to page 47, and on the 3rd paragraph you'll find an answer.'

With a unique URL, you can respond in Chatter, email, in the communities, etc. sending your end users to the exact answer they are looking for.

Why do any of this?

The goal of your end user documentation is to reduce the number of hours you spend explaining workflows, and reduce the number of hours end users spend looking for answers.

If you can remove hurdles your end users have to jump over in order to find answers, they will reference your documentation. And that will create self-sufficient end users who do the job correctly, in less time, and without constantly involving you.

Note: HubSpot, Metric Insights, and Skuid all use ScreenSteps to write great end user documentation.

A user guide is essentially a book-length document containing instructions on installing, using, or troubleshooting a hardware or software product. A user guide can be very brief—for example, only 10 or 20 pages or it can be a full-length book of 200 pages or more. While this definition assumes computers, a user guide can provide operating instructions on practically anything—lawnmowers, microwave ovens, dishwashers, and so on.

The more complex the product, the greater the page count. When this happens, some elements of the user guide get split out into their own separate volumes—especially the installation procedures, troubleshooting procedures, and the commands. A user guide can even contain a brief tutorial—for example, getting users started using the product—but if there is too much tutorial, it too goes into a separate book.

See examples of user guides.

Style and Format for User Guides

A user guide is a combination of many things presented in this online textbook. At its core is instruction writing; you need to be good at the writing style, headings, lists, notices, highlighting, tables, graphics commonly used in instructions. (For an overview of these elements, see the page-design chapter in this online textbook.) As a set of instructions, a user guide should use the style and format that is presented elsewhere in this online textbook:

• Headings. Use headings to mark off key contents of the information so that readers can find it quickly. See the chapter on headings for details on planning and designing headings.
• Lists. Use numbered and bulleted lists to help readers scan information quickly. See the chapter on lists for details on planning and designing lists.
• Special notices. Use special notices such as warnings, cautions, and notes to alert readers to potential problems or emphasize special points. See the chapter on notices for details on planning and designing notices.
• Instructional design. In general, use the standard design of instructions; primarily, this means task-oriented headings and sections and numbered vertical lists for actual steps that readers are to perform. See the chapter on instructions for details on planning and designing instructions.

Instructions—and therefore user guides—also make abundant use of:

• Graphics. Show readers key components of the objects they will be working with, before and after views, and illustrations of key actions that readers must perform. See the chapter on graphics for details on planning and designing graphics.
• Tables. Provide statistical information and other such details in easy-to-access table form. In user guides, tables are particularly useful whenever reference-type information must be presented. See the chapter on tables for details on planning and designing tables.
• Highlighting. Use a consistent and standard scheme of highlighting (bold, italics, alternate fonts, color, caps, and so on). See the chapter on highlighting for details on planning and designing highlighting guidelines.

Components of User Guides

As a book, a user guide must have some combination of the standard book-design components such as the following:

• Front and back covers
• Title page
• Edition notice
• Trademarks
• Disclaimers
• Warranties
• License agreements
• Safety notices
• Preface
• Appendixes
• Glossary
• Index
• Reader-comment form

There is no standard combination or sequence of these elements; every company does it differently. Details on the contents, format, and design of these elements can be found in the book-design chapter.

Information Included in User Guides

Here's review the common contents of user guides:

• Instructions. The most obvious are those step-by-step directions on how to assemble, operate, or troubleshoot the product. Instructions in user guide should generally be task-oriented—that is, written for specific tasks that users must perform. Instructions should generally use vertical numbered lists for actions that must be performed in a required sequence. Similar or closely related instructions in user guides should be grouped into chapters.
• Precautionary information. You'll see notes, warning, caution, and even danger notices in user guides. These represent liability concerns for the manufacturer of the product.
• Reference information. User guides typically contain plenty of reference information, but only up to a certain point. For example, if there are numerous commands, a separate book for commands is necessary. Reference information in user guides is often presented in tables: columnar lists of settings, descriptions, variables, parameters, flags, and so on.
• Getting-started information. Some user guides will actually include brief tutorials that will help new users get acquainted with using the product.
• About the product. User guides also provide some description of the product, a review of its essential features or its new features. Sometimes this information also gets put into a separate volume, if it is extensive. Typically, the volume will be called something like 'Introducing New Product....'
• Technical background. Sometimes, users guides will include technical explanations of how the product works, what physical or chemical principles are essential to its operation, and so on. For example, you will see considerable background in user guides for graphic or audio programs—you can't operate them without understanding the concepts of brightness, saturation, and hue; μ law, A law, and other such.

Descriptive Examples of User Guides

Consider these examples.

Note: Not all of the following styles and formats are not necessarily recommended. Get in touch using the e-mail address at the bottom of this page if you have questions.

Delarina WinFax LITE User's Guide. This book is 5.5 × 8.5 inches and under 150 pages. It uses by-chapter pagination, with new chapters and sections beginning on a righthand page.

• Covers: On the front cover, you see the full book title, a version number, the company name with its logo, and warning that the book is not for retail sale. The back cover contains advertising material—rather atypical for user guides—on the product's best features, special offers on the full version, a 1-800 number to call, and the book number.
• Title page: The first page inside this user guide is the title page, which includes the product name, the book title, the book edition number, the date of the edition, the company logo (which includes its name), several addresses for the company, and the not-for-retail-sale warning. The company name has a registered trademark symbol beside it; the product name has the trademark letters beside it. No trademark symbols are shown on the front or back covers. A greener approach is to omit the title page, since it is practically a duplicate of the front cover, and put the edition notice on the back of the front cover.
• Edition notice: On the back of the title page is the edition notice. This edition notice includes the book title, a copyright notice, legal statements concerning copying the book, list of trademarked product names occurring in the book, and the document number.
• License agreement: On the next page is the software agreement, a two-page thing that outlines permitted uses of the software and related warranties.
• Table of contents: The TOC begins on a right-hand page numbered 'i' and lists up to level of headings within the chapters.
• Headers and footers: The book title is used for both the left and right footers: on the left page, the title is right-aligned; on the right page, the title is left-aligned. The page number appears opposite of both footers, and a solid ruled line is placed just above both footers. The chapter title is used for the inside header on each page; the current heading is used for the outside header on each page. A solid ruled line is placed just beneath these headers.
• Preface: The overview which is treated as chapter 1. It contains some promotion of the product, a diagram of the product's many uses, hardware and software requirements on its use, an overview of the manual contents, and instructions on how to get help.
• Body chapters: Chapters use the following design features:
  
  • Headings—First-level headings are about 1 point smaller than chapter titles, left aligned, with a solid ruled line just below. Second-level headings are about 2 points smaller, left aligned, with no ruled line. Third-level headings are the same size as body text but use bold italic Arial and are placed on the left margin.
  • Graphics—Numerous screen captures are used through the book; they are all centered.
  • Highlighting—Text that users must type uses a sans serif type (probably Arial) as do screen buttons, options, field names, and system messages. Bold is used for simple emphasis.
  • Index—The book ends with a 10-page index whose page are numbered with lowercase roman numerals starting at i. The index uses the standard but does something unusual with entries. It uses a table-of-contents format for the entries and their page references, connecting them with the sort of leader dots you'd see in TOCs.

IBM Aptiva Reference Guide. This book is also 8.5 × 5.5 inches. It is uses consecutive page numbering throughout the book and is about 120 pages long.

Technical Manual Writing Software

• Covers: The front cover has a graphic design with stylized numbered 1, 2, and 3 along with large grid pattern and various sorts of shading. The three elements of the book title are placed at the top, upper third and bottom of the area, respectively. You also see the words 'information,' 'getting help,' and 'troubleshooting' which seems to float between the second and third title elements, giving readers a more detailed sense of the book's contents. The back cover continues the grid pattern and includes the IBM logo with the part number of the book, its print date, a statement that the book was printed in the 'USA' and a bar code for the book number.
• Title page: This page contains the words 'Aptiva Reference Guide' in large serif letter in the upper right of the page—and that's it!
• Edition notice: The edition notice occurs on the back of the title page. It is pushed to the bottom of the page and uses a smaller type size, probably 7-point, for its body text. The heading for the edition notice is the edition number followed by the month and year of the edition. The paragraphs of the edition notice states that the book is provided 'as is' without any warranty, that the book is for multiple models of the product and that portions of it may not refer to the reader's own particular model. Also included are an address where comments can be sent, a 1-800 number to request additional copies, and the standard copyright line.
• Table of contents: The TOC is an unusual design in which all entries are left aligned in the center of the page, with the page numbers to the left about an inch. First-level entries use bold. TOC begins on page iii.
• Notices section: The first body section of this manual is for notices—specifically, trademarks, highlighting conventions used in the book, safety notices, and regulatory (communications) notices. The section begins with its own title page on which is displayed the word 'Notices' in a large serif font in the upper right corner and with a grid and shading design similar to that on the front cover. The text of the notices section begins on a right-hand page as does the chapter title page.
• Body text: Here are the key design features of the body text:
  
  • Text—Text for this book is indented nearly 2 inches. Body text is a rather small sans serif font, probably Helvetica, probably 9 or 10 points. The hanging-head format is used.
  • Headings—First-level headings align to to the far left margin, use a blocky bold sans serif font with a solid ruled line above. Chapter titles use a large gray serif font in the upper right corner of the first page of the chapter. Second-level heading align with body text, use sentence-style caps (as do first-level headings) and use the same font as do first-level headings but about 2 points smaller.
  • Highlighting—In stepwise instructions, the following elements are bold: buttons, tabs, menu options, menu names, keyboard key names, icon names, parameter settings. Names of disks supplied with the product are in italics. System messages are in regular roman and double quotation marks.
  • Steps—Instructions sequences are introduced with a gerund-phrased heading in the bold font. Substeps or alternate subtasks use infinitive phrasing with the same font but smaller and are punctuated with a colon. Actual steps use a number in the same smaller font without a period.
• Headers and footers: Only footers are used. Bold page numbers (using the same font as the first-level heading but much smaller) are on the outside; the current heading, not chapter title, is centered and in a serif italics font using sentence-style caps.
• Special notices: This book uses a light gray box with a white checkmark in it to call attention to special notices. The text of the special notices is the same as the footers: small italic serif font. Usually, the checkmark box is located on the far left margin and the notice text is aligned to the normal body text. Where possible, the checkmark box and the notice text are in the open area between the far left margin and the body text.
• Troubleshooting section: The body of this section begins with a flowchart that must be meant to orient a user to the overall process of troubleshooting and to the different troubleshooting resources available. The next section consists of common questions with actions to take depending on yes or no answers. The text of the actions is bulleted or numbered depending on the content and contains cross-references to other areas of the troubleshooting information. The next section is designed in two columns, the left column with the heading 'If the problem is...' and the right column with the heading 'Here's what to do...' The problem statement in the left column is in bold. the next section is similar except that it lists error codes that are displayed on the computer and actions to take.
• Index: The book has a 6-page index formatted in 3 column. Two levels of index entries are used. The page references are set about a half inch away from the text entries.

User Guides Manuals And Technical Writing: A Guide To Professional English Pdf

Process and Internal Documents for User Guides

Technical Writing Instruction Manual

An important part of user guides—in fact, of almost any technical document—is the process that produces it:

1. Initial planning. Early planning on a user guide involves needs assessment (is any documentation needed at all?), audience analysis (who will be using the user guide; what are their needs?), task analysis (what will users use the product for; what are their common tasks?), library plan (what books and media, in addition to a user guide, are needed to support the product?), and so on.
2. Documentation proposal. If you are working freelance or as part of an independent documentation firm, you may have to write a documentation proposal in an effort to win a contract to do a certain technical documentation project.
3. Documentation plan. User guides need documentation plans, which are internal supporting documents that specify content, audience, design, format, production team members, schedule, and other such information about a documentation project and its 'deliverables.' The documentation plan resembles the documentation proposal in certain ways, but the plan represents an established plan agreed upon by everybody involved in the production process (and that means both the user guide and the product it documents).
4. Prototype and specifications. Important planning tools, which also serve as useful reference tools during a documentation project, include the prototype of the user guide and the specifications for the user guide. The prototype is a dummy version of the book with all planned components of the book (see the list on book-design components) and all planned elements (see the list under format and style). However, the prototype uses 'greeked' text (also known as Lorem ipsum like the following, instead of real text:
   

   Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullam corper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan.

   
   Typically, the prototype of the user guide is very brief: it need include only as many pages as it takes to illustrate every unique textual component and textual element that will be used in the user guide.
   Specifications are descriptions of a book design in table form. Specifications describe every unique component or element of a book, so that it can be recreated by someone who might not have access to the electronic files, templates or styles of that book.
5. Template and style catalog. A well-designed user guide, and a well-designed process to produce that user guide, should include templates and style catalogs. A template is an electronic file that defines such aspects of the user guide as page size, headers and footers, page-numbering style, regular and special page layout, and other such detail.
   A style catalog is also an electronic thing that defines the format and style of textual elements such as headings, headers, footers, lists, paragraphs, tables, and so on. For example, a style for a 'heading 1' might specify 24-point Arial bold with 24 picas above and 12 picas below. Styles help you create a user guide more efficiently; styles also help you maintain consistency in the format and style of that user guide.
6. Multiple review drafts & sign-off. A good process for the production of a user guide also includes several drafts that editors, technical experts, usability testers, and documentation team members can review and provide comments on. You as writer then implement those comments and produce a new draft for these same people to review again. When everybody is satisfied with the draft of the user guide (or worn out or out of time), they sign off on the user guide, and it can then go into 'production,' which means producing the finished bound copies or the PDF that is made available to users.

As you can see, a user guide brings together many of the topics covered in this online textbook. If you are taking a technical writing course, you probably cannot implement all these features and phases of a user guide. Get with your instructor to see which are required.

I would appreciate your thoughts, reactions, criticism regarding this chapter: your response—David McMurrey.