NOTE: This is second in a series of three articles outlining key elements of a good user documentation process. (To read first and third articles in this series, go to http://www.divinewrite.com/docoprocess1.htm and http://www.divinewrite.com/docoprocess3.htm.)

State your goals

Generically speaking, your goal statement should indicate that you hope to create a suite of documentation products that will satisfy audience requirements. Specifically, you’ll have a number of sub-goals. (TIP: It may help to remember that goals you set here will need to be used to measure success of your product through your own in-house testing as well as through evaluative user research.) Such sub-goals may include:

•Ease of use •Accessibility •Helpfulness •Accuracy •Relevance •Comprehensiveness •Adherence to style guidelines •Correct spelling and punctuation

Write your Concept Specifications

Your goals set, you can start to contemplate what you’re going to produce. The first step is to create some concept specifications. Simply put, concepts specs are very high level overviews of what you’re proposing to produce. For example, your concept spec for online help might state that you will be producing a product that allows user to access information using a TOC, an Index, and a Find. It might suggest some possible GUI features of these elements, but it will not lay down requirements; just possibilities. The concept spec for your manuals might state that they will be professional looking, will contain many professionally drawn pictures, will have adequate white space, will be stylish, will be divided into chapters to match task oriented nature of online help, etc.

Generally, product you’re proposing could be implemented in a number of different ways. You should write one or more concept spec(s) for:

•what components documentation suite will consist of (online help, printed manuals, tutorials, overviews, etc.) – “Documentation Products Concept Specification” •the types of information your documentation will contain (e.g., structure of TOC, are you going to follow minimalism practices?) – “Documentation Content Concept Specification” •the functionality and user interface of your documentation suite (e.g., how it will work and how audience will interact with it) – “Online Help User Interface Concept Specification”, “Printed Documentation User Interface Concept Specification”, etc. •the delivery method (how you will deliver help to users and how you’ll update it) •what languages documentation will be produced in

Design some possible implementations

Now that you’ve decided roughly what you’d like to produce, you can design some possible implementations of it. Your designs will be very high level and they may not actually work (they may actually be just paper prototypes).

With most other considerations already finalised through your user requirements research, these implementations should only differ as a result of:

•the technologies behind them •the tools used to create them •the overall look and feel

You need to learn as much as possible about these things, in order to determine what is actually possible, successful, effective, etc. You should be aware of current trends, literature, white papers, etc. This information can be obtained from a variety of sources. Some good places to start include:

•List servers •Conferences •Books •Other publications •Other writers •Other products

Conduct usability testing on your prototypes

Model (prototype) your designs for decision makers and audience samples. This allows you to pick best features from each design (and to determine priorities for them). Select a design (or merge multiple designs) that you believe best satisfies user requirements. This process may be iterative. At end of this stage, you should know enough to detail exactly what you’ll be producing (including what help platform and tool you’ll be using).

TIP: For details on possible research methods, take a look at Managing Your Documentation Projects by Hackos (1994) esp. pp.446-447, User and Task Analysis for Interface Design by Hackos & Redish (1998), Social Marketing: New Imperative for Public Health by Manoff (1985), Designing Qualitative Research 2nd Edition by Marshall & Rossman (1995), and “Conducting Focus Groups – A Guide for First-Time Users”, in Marketing Intelligence and Planning by Tynan & Drayton (1988).

Write your Requirements Specifications

Requirements specifications detail exactly what you must end up with. These specifications should contain as much detail as possible about features and functionality of documentation product (not how you’ll go about building it).

Requirements specs are basically an evolution of your concept specs. Once you begin work on your requirements specs, concept specs are effectively frozen. You should write one or more concept spec(s) for:

This works because programs like Outlook can read different types of files. The file we're going to be creating is called a vCalendar file -- be aware this will only work if your visitor has Outlook 97 and above (Outlook Express is no good here).

What we'll be doing here is creating event on our computer in form of an appointment on Outlook calendar. Then, we'll export it to a file our visitors can click on, and when they do, it'll import all info about meeting right into their Outlook calendar.

Let's get started. Open Outlook, go to your calendar and find correct date, and double click.

Type in a subject, this will be your event's title. For location put in something like URL if this is an Internet thing or a phone number with a passcode if this is a phone-based teleseminar.

Then choose a start time and end time, in your time zone. The COOL thing about this is when user adds this appointment, it will appear adjusted to their own time zone.