TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Getting Started Manual From:Barbara Roll <broll -at- MICROSOFT -dot- COM> Date:Tue, 15 Sep 1998 08:30:08 -0700
I think a Getting Started manual should contain information about the
How to use the online help provided
Overview information of the system components.
My employer mentioned including system requirements and customer
specific information but I am not sure those types of information should
be included. Any feedback would be greatly appreciated!
Getting Started is often the first things readers will review. Most users
refer to help only when they have a problem, but a getting started book will
be read from cover to cover by some users (especially if it's short and
One thing I believe users expect to find in a Getting Started is
installation and setup...what do they need to do before they can start
banking? Any potential problems they may encounter should be addressed
within the context of setup.
Otherwise, I agree with the writer who proposes common tasks, such as making
a deposit, checking a balance, making a payment. Getting the user through a
few common tasks with help them understand what they can do with the product
as it teaches them how the product works (including logging on and off,
screen components, navigation.) Users already do these tasks, so you are
presenting product-specific information in a familiar (and therefore
I would include a section on using the online help following the information
on common tasks. You can present it as "where to go next." It's especially
nice to break out this information by user type. For example, you might
encourage an advanced user to explore the product on their own, but steer a
novice toward more help.
Systems requirements, if included at all, should be in an appendix. In my
opinion, the writer who pointed out that system requirements need to be
presented before the user purchases the product has the right idea.