create technicl documentation
create technicl documentation
Unit Purpose
On completion of this unit, the trainees should be able to create technical documentation.
This broader view, in which all documents that are generated during the product life
cycle are viewed as part of the technical documentation is certainly justified. After all,
the aim is to make available the technical know-how and product history for
subsequent users of the information.
The focus for service providers in the field of technical documentation is, however,
mainly on documents that are required after the production process —the reasons
are simple:
Computer users need documentation so that they can make the best use of their
computers as work tools. User documentation helps users to learn a system and/or
application software, and to get help when they experience problems. Creating user
documentation involves the steps of planning, writing and reviewing user
documentation to ensure it meets organisational and industry standards, as well as
user requirements.
FActivity 1
What user documentation are you familiar with? Make a list of the different kinds of
user documentation you have used or you are familiar with, both personally and at
work. /5 points/
After completing, checking points are:
Product definition and specification, TD is prepare for ..., design, descriptions of features, etc.
F Activity 2
Think of the types of user documentation you have seen at a workplace. Do some of
your examples include the following? [N:B. Data base]
Documentation Description
type
Project specifies the detailed business requirements of the
specifications project including how the system will work and the
underlying functionality
Reports produced by the system, program, network or application
Help resources Provides online Help, quick reference cards, scenarios,
FAQs (Frequently Asked Questions). Users can search for
help on using of a specific system, program, network or
application
User manual/guide describes how the user will use a system, program,
network or application to do their job
F Activity 3
Think about documentation you have used and recall why you needed to refer to it.
What was the main purpose of the documentation? What did it enable you to do?
These are some examples of user documentation and their purpose.
Examples Purpose
A project specification, training manual, to learn how to use a piece of
user guide, tutorials or help that provides software
step by step guidance in how to use the
software.
A training manual, quick reference guide to refer to a specific feature of a
or user guide that provides detailed piece of software
commands and specifications of a
software package to assist with
troubleshooting problems.
Users’ needs
A need analysis is a process where the needs of the target groups for the
documentation are identified and analysed to decide the most suitable content and
format of the documentation. /Q. give your example for a need analysis/analysing the
need of target group/. For example, Data Entry staff in a call centre need to
know how to correctly enter data in a database so that orders can be
generated correctly from a database.
For training materials and online help a needs analysis should be conducted in person
with the staff who will need the documentation. For other documentation a look at the
needs of the users without speaking directly to staff is sufficient.
After considering user characteristics and needs, possible solutions can be found, for
example:
It’s almost impossible to cater for all these variations. However in preparing
documentation for a new user, you would obviously not confuse them with technical
jargon on the first page! You need to find a balance and remember that any
documentation must be consistent with the organisation’s policy,
conventions and standards.
For any form of documentation to be useful it must be designed with the needs of its
potential users in mind. An analysis of the requirements of the users, and the way their
needs can be effectively addressed, is a critical step in the process of determining
documentation requirements.
It’s a good idea at this stage to think about the content that you will include in the user
documentation. This is so you can estimate the number of pages, the complexity of
the content and what the graphic and text components will be.
The content will have some influence on:
design of the documentation, including layout, use of text and graphics
medium, eg paper-based or online
the time and resources needed to develop the documentation
Media for user documentation
You can consider paper-based documentation, online documentation or a combination
of both. The media type you choose will be influenced by the:
F Activity 4
Think about when you would be most likely to use paper and when you would use
online.
Paper is appropriate in most circumstances. It is the most commonly used method of
delivering documentation, so most people are used to it and like it. However, when
staff are dispersed across a country or around the world, online delivery is best.
Everyone can access the same documentation and only one version is available.
Where user documentation is going to be used primarily as a help tool, then online
help is most appropriate. It allows for easy searching across the documentation.
Designing templates
Once you have determined the documentation requirements, you can develop a
template that meets those requirements and makes the job easier. A template is a file
that contains a standard layout, styles and fonts that are used in the production of
the documentation.
When you want to create a file for user documentation, you open the standard
template, usually in Word, and the layout, fonts and styles are already set up in the
document. All you need to do is start writing. Everyone uses the same template, so
there is a consistent look and feel to all of the user documentation.
The template may be:
a Word template
an HTML template
an online help template.
The medium will determine what kind of template you use.
Features of templates
Paper-based documentation
Features that may be included in paper-based documentation are:
table of contents
columns and tables
page and section numbering
headers and footers
graphics and text surrounds
substantially chunked information.
Online documentation
Features that may be included in online documentation are:
table of contents hyperlinks
tables
links to other pages/sites
navigation icons
usability/functionality
heavy use of graphics.
The template should be designed in consultation with users or a subject expert. Once
the template has been designed, it should be distributed according to the user
documentation policy, or, the agreed review process if you are working towards final
sign-off.
how to use the application, i.e. the steps required to complete various tasks
screens dump with dummy/model/ data to give the user a complete picture of
how to enter data and process the data [model]
tutorials
Note that this guide can incorporate a training resource such as a tutorial.
The technical manual generally contains the technical information such as:
Before you can start writing documentation, you need to know how the system,
program, network and/or application that you are documenting works.
project specifications
online help
procedure manuals.
These documents will show you how the system, program, network or application
works. It should also show you what the organisation’s work procedures are and how
to apply them.
As a confident user of the system you can begin to write the documentation using the
agreed template and relevant tools. You will need a template for user documentation
and the relevant tools for development.
Planning content
In the same way that you plan any piece of writing, you will need to create a plan for
writing the documentation. Before you write the user documentation, write an outline
of the contents. Organise the content into:
1. Main headings
2. Sub headings
3. Points under each of the subheadings.
It might be necessary to approach a subject matter expert to assist with the planning
or it might be sufficient to use any existing documentation as a model for the new
documentation.
When writing the content, it is important to follow effective writing principles. Other
features such as graphic design and navigation will help user documentation work for
users. Along with getting the content right, you’ll need to use sound principles for
layout and usability as well.
A final stage in the development of your documentation will be testing the
documentation with real users, then revising the documentation and testing it again.
So you’ll have the opportunity to adjust content and other features to better fit the
needs of your target users.
Tips for writing and designing effective user documentation
Use this as a checklist for planning the features of user documentation.
Content features
Give a brief introduction where you state the purpose and objectives of the
documentation.
Include a table of contents or index
When writing, keep the users’ needs in mind, i.e. put yourself in the users’ place.
Layout features
Make the document structure as simple as possible and logical by providing cues to
locate information.
Ensure good usability, especially for online documentation.
Cross-reference information, e.g. use hyperlinks in online documentation.
Warnings, comments and help should be well-organised and visible.
Aim for a clean design for text styles and layout that is consistent across all pages.
F Activity 5
What do you think may be the benefits of involving users and accepting their
feedback?
The end product is more closely aligned with the needs of the users.
The process of creating user documentation is much simpler due to the expert
knowledge users bring.
Developer tools
The writing tools you use will be determined by the medium — paper-based or online.
Tools (software) can include applications for:
word processing
image editing
image conversion (to web-ready)
painting and drawing
HTML conversion/authoring/editing
FTP utility
site management software
multimedia or slide show authoring
audio and video equipment and editing software.
QA checklist
A standard checklist should be used to check the documentation. A QA checklist
contains a list of standard formats and styles that reflect the organisation’s user
documentation standards.
The purpose of the checklist is to ensure the documentation standards are followed
and that all user documentation is consistent in style and appearance. Once the QA is
complete, the documentation can be sent for a formal review.
The following table lists some of the criteria you could include in a QA checklist.
Usability testing
Online user documentation requires a test for usability. This means that the interactive
design and navigation should be tested to see whether the user can easily find the
information they are after.
It is preferable for usability testing to be performed by a subject matter expert or a
user (since they will be using the documentation when it is finished). The
organisation’s usability standards can be put into the QA checklist.
F Activity 6: What makes a good user guide?
In your home, locate a manual that you think is effective for how to use one a home
appliance or other technical equipment, such as a microwave, clock radio, DVD player,
computer peripheral, etc.
Look at the manual and try to identify features that make the manual a
good ‘user guide’. List those features.
Feedback
F Activity 7: Usability
Using the same manual you found for Activity 5, conduct a usability test. For example,
think about some specific information you want to find and see how easy it is to find it.
Why was the information or instruction easy or difficult to find?
Feedback
Feedback
quick-reference cards
training manuals or tutorials
flowcharts that show the logic of the application/software
data models that show the fields in a database
system architecture diagrams that show the network layout
template design and macros.
Feedback
Feedback
Steps
1. Double-click the desktop icon for Internet Explorer to open your browser.
5. The website will appear on your screen, within the browser window.
1 the designated project team members who have knowledge of the system,
program, network and/or application
2 a subject matter expert.
Review process
Person Role
Technical writer The Technical writer creates the user documentation. They
then manage the process of obtaining feedback from the
project team, SME and key stakeholders and changing the
documentation to meet their needs. The documentation is
then handed to the Project Manager once final sign off is
obtained.
Project team Generally, a small group of members of the project team will
members be designated to perform an initial review the
documentation. If changes are required, the document will
be returned to the Technical writer and the review process
will start again.
Subject matter The documentation will then go to a subject matter expert or
expert (SME) a group of subject matter experts for review. If changes are
required, the document will be returned to the Technical
writer and the review process will start again.
Business unit The business unit stakeholders are generally senior
stakeholders management who have a stake in the system, program,
network and/or application you are writing the
documentation for. These people are generally listed on the
Project Brief, depending on the organisational policy.
Version control
When writing documentation of any kind, it is a good idea to have version control
process in place to ensure that changes are not lost and versions are not confused.
This will often be outlined in the user documentation policy.
You may have a personal system that you prefer or may like to use a standard system.
Either way, it is critical to establish how you are going to name and number the
various versions of your documents and to communicate that process to other writers
and reviewers so that everyone is on the same page.
For example, the first draft of a user guide is called ug_draft0.1. After 2 reviews and
changes it becomes ug_draft0.3. When the document has completed its final review
and has been signed off, it becomes ug_version 1.
Once the documentation has been reviewed and all of the reviewers are happy with it,
you can send it to the relevant people for sign off.