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.
I find that the keys in documenting complex conditional steps are to hilight the
current goals (dividing steps & sub-steps), as well as to find the
similarities, so that the conditions can be condensed. For example, in Kim's
situation, the first step is to get to the Patient Header. You might have
instructions as follows:
1. Access the Patient Header
When the Patient Header Screen appears, continue with step 2. You may
already see the Patient Header Screen in front of you.
* If nothing is happening, ......
* If you see the Patient Enquiry Screen, .... then continue with step 2.
2. Update the Patient Header (or whatever)
You should see the Patient Header Screen. If not, check step 1 before
Note that I put the "nothing happening" step before "Patient Enquiry", because
after following the instructions for "nothing happening", the user may still have
to deal with the "Patient Enquiry Screen". I also hilight the "major task" - the
point of all those complex conditions was to "Access the Patient Header"; with
this task hilighted, a user who immediately gets to this screen (or understands
how to get to this screen from the other possibilities) can skip over the rest of
your explanations and move on to step 2.
For some situations, you may find that a table works better than bullet points
or a long list of conditions. For example, I have a page where I explain price
calculations. These calculations depend on many possibilities (e.g, which
combination of part/price/other factors the user has changed). The table hilights
the factors the user already knows (which elements he changed) to quickly
pinpoint the necessary information (explanation of the particular calculation).
If you find there are lots of steps and groups of steps which are conditionally
repeated, you might find that a flowchart works best for you.
- Michele Marques
mmarques -at- cms400 -dot- com
> For example, if the user wants to select a patient using the Medical
> Record Selection box, these things may happen:
> 1. The Patient Header screen may automatically appear.
> 2. The Patient Enquiry screen may automatically appear.
> (The user must then select a visit and the Patient Header
> screen appears).
> 3. Nothing happens. The user must press <Tab> or
> a. The Patient Header screen appears.
> b. The Patient Enquiry screen appears. (As above,
> the user must select a visit, and the Patient
> Header screen appears.)
> The user needs to get to the Patient Header screen to begin the
> Registration function.
> I've checked the archives, but the suggestion to put all of these
> variables into a bullet list doesn't work well for me because this
> information seems too dense for bullets. There also seems to be too many
> hierarchal conditions for a bullet list.
> Any suggestions? Our users are registration staff, most of whom are
> comfortable with computers, but do not think of themselves as
> Kim Forbes
> Technical Writer
> Boston, MA
> forbes_k -at- a1 -dot- tch -dot- harvard -dot- edu
> Get Your Private, Free Email at http://www.hotmail.com