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.
Flowcharts -- information mapping and best practices?
Subject:Flowcharts -- information mapping and best practices? From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L Writing <techwr-l -at- lists -dot- techwr-l -dot- com>, "Boudreaux, Madelyn (GE Healthcare, consultant)" <MadelynBoudreaux -at- ge -dot- com> Date:Sat, 06 Jun 2009 08:18:50 -0400
Madelyn Boudreaux wondered: <<... imagine my horror at being given a
flowchart and asked to do the same. As it turns out, what I've learned
about tables does not translate to flowcharts, with which I have
almost no experience.>>
Rule 1, which most product developers never learn, is that you must
test the product (here, a flowchart) to ensure that it actually works
as planned. If not, figure out why and solve the problem. Imagine how
many millions of dollars and hours and thousands of ulcers could have
been saved if all engineers and programmers and Web designers and
graphic artists actually tested their own products before unleashing
them on the world! My first impression of your chart (see below) is
that it should be a table; flowcharts are best used for decision trees
and sequential procedures, but I don't see decision branches or
sequential dependencies, suggesting a flowchart may not be the best
choice.
Rule number 2 of flowchart design is, like documentation design, to
put yourself in the shoes of the user of the product, and imagine you
were about to use the flowchart: What is the first decision you must
make? What is the second? What is the third? Are there any
dependencies (choices that must be made before other choices become
possible)? Prioritize the information design on that basis, so that
users an reach their goal as quickly as possible, and can retrace
their steps quickly if they take the wrong branch. Somewhere in my
file cabinet I have a wonderful paper by Dutch researchers that
demonstrated convincingly that the most efficient information
hierarchies are broad and flat: that is, they have more choices at the
start, and few branches below each choice, so the penalty for
retracing your steps if you choose wrong (the number of branches you
need to retrace) is small.
Rule 3 is that each branch should have the maximum efficiency in
dividing up the possibilities that stem from that decision; that's how
you shorten the decision process. That is, if you don't know the most
likely paths (series of decisions) that people will take through the
information, you should arrange the information so that each branch
cuts the subsequent options roughly in half. That way, the average
user can focus on a rapidly narrowing collection of choices. This is
why most flowcharts are dichotomous (i.e., each decision point only
has two branches): each branch divides the remaining choices in half
at most steps.
I speculate that dichotomous branching arrived via a long history of
creating such keys in botany (for identifying species), as that's the
area I'm most familiar with in this context. Because this approach is
efficient, it became a best practice that has rarely been challenged.
But the research I've read and some more radical botanical keys I've
used suggest that users should be able to easily handle at least three
branches per box, and possibly more, and that designing on this basis
might improve efficiency enormously. For example, rather than reducing
the subsequent choices to 50% of the total, as in a dichotomous key,
each decision point in a "trichotomous" <g> key would reduce the
subsequent choices to 33% of the total. (This is why the Dutch
research demonstrated the advantage of flat hierarchies: rapidly
declining number of options after each decision.) If you have the
opportunity to test this with your actual audience, it's worth doing.
This is impossible to do well without knowing the actual content of
each box, but a few thoughts: Is the first box really necessary? A box
that starts the process by leading to only one other box should be
questioned. The current chart says you only do the design input for
the first document, not for the other two. Seems suspicious to me! <g>
But if it's true, why not merge those first two boxes into one box?
The rat's nest of crossing lines below the two pink documents isn't
good. When it isn't possible to unpick the knots that overlapping and
crossing lines create by repositioning boxes, there are two main
options: First, repeat boxes; for example, since all three pink boxes
connect to the same three or four blue documents, you should probably
repeat those blue documents below each pink box, with any useful
changes that result from differences in the pink boxes specified.
Second, you can create exit arrows from a box with many outputs that
are numbered 1, 2, 3, etc. and start a new subordinate flowchart
(numbered 1, 2, 3, etc.) to represent the destinations of each of
these jumps.
Merge lines that go to the same place into a single line rather than
using separate that produce a profusion of crossing lines. Here, the
overlapping blue lines at the bottom should be merged _immediately_
below the final row of blue boxes into a single line with two
branches: one that immediately goes left before branching to the
orange documents, and another that immediately goes right to the blue
document at the top right. There are possible dependencies that need
study; it's not clear why, for example, you would end up at the top
right blue box after navigating three to four levels down into the
hierarchy. There should be a shortcut that leads there right from the
start, in a single step rather than three steps.
------------------------------------------------------------------------
Geoff Hart (www.geoff-hart.com)
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
------------------------------------------------------------------------
Effective Onscreen Editing: http://www.geoff-hart.com/books/eoe/onscreen-book.htm
------------------------------------------------------------------------
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
