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.
Kim Portonova is <<...documenting a quick reference guide
for our patient accounting, medical records, and patient
registration system. The interface is clunky, and the
procedures have many complex variables [with lots of
decision points]>>
In a case like this, you probably have three options,
depending on how complex the material actually is. If the
numbers of permutations and steps are relatively small, you
could use a table. For example:
Select What appears Steps to follow
----------------- ----------------- ------------------
Patient record Screen A Step 1
Step 2
Screen B Step 1
Step 2
Screen C Step 1
Step 2
You can also use what we botanists call a dichotomous key.
The key <sorry!> here is that you jump from the current
sequence of steps to a number further down in the list at each
decision point. In the example below, the only dichotomies
(branches) I've created are in steps 1 and 6; you could create
such decision points wherever necessary. You can also create
more than 2 options at each point, though restricting yourself
to 2 branches at each numbered step is more traditional.
Here's what this might look like:
Select Patient record:
1. Screen A appears: go to step 2
1. Screen B or C appears: go to step 6
2. Step 1 for Screen A
[more steps for Screen A, with the numbers 3, 4, and 5, any
of which could have additional branches or jumpoffs]
6. Screen B appears: go to step 7
6. Screen C appears: go to step 12
[more steps, starting at 7, any of which could have branches;
steps for Screen C begin at number 12.]
A more intuitive version of the same thing would be to create
a flowchart, with arrows showing the sequences of steps and
branches representing decision points that lead to another
series of steps. My only reservation about flowcharts is that
they're not intuitive to everyone and can be difficult to create
so that they're effective. But once you know how to create
and use them, I find them much more efficient than
dichotomous keys and about as good as tables; they're also
far more flexible than tables if you have tons of columns to fit
into the table. The research I've seen on this subject supports
that conclusion, though of course all such research is highly
context-dependent.