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: Number of steps per procedure From:"Tim Altom" <taltom -at- simplywritten -dot- com> To:"Tara English-Sweeney" <tesweeney -at- novadigm -dot- com>, "TechDoc List" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 18 Oct 2000 17:40:01 -0500
The number of steps in a procedure must be as numerous as the user requires.
I was once on an ISO 9000 project where we could have literally written a
single step for a procedure: Fix the analyzer. The technicians were all
highly skilled and experienced and needed no help. We documented the steps
only for training and admin purposes.
The 5+- garbage is so much old-writer's tale, foisted upon us by a certain
methodology peddler. It's applicable only, solely, and exclusively to
short-term memory study, NOT to procedures. If you doubt this, take the
trouble to look up Miller's own paper on the misuse of his initial research
results. We provide a link to it from our website.
The only problem with plentiful steps in a procedure is that it can appear
too formidable. But some tasks ARE formidable, and need to be documented
that way. Our general rule is that if you can't identify the attributes of a
typical user, break the task down into smaller steps. That way skilled users
can breeze through them, while novices can benefit from the granularity. The
choice of step numbers should never, never, never be based on spurious
claims by a methodology vendor, but only on the tested needs of the user.
And I do mean "tested". Experienced SMEs and users may balk at granular
steps, but most of those doubters are shocked when they see how many
mistakes other users make if the steps aren't clearly spelled out. Help desk
personnel have nearly kissed my feet because I advocated strongly breaking
the tasks down into dozens of steps, instead of the five or six that
experienced users were arguing for. They knew far better than the SMEs just
what kinds of users they faced. That being said, I've always preferred
testing to help desk opinions. Testing is the only objective way to gauge
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
Check our Web site for the upcoming Clustar class info http://www.simplywritten.com
----- Original Message -----
From: Tara English-Sweeney <tesweeney -at- novadigm -dot- com>
To: TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com>
Sent: Wednesday, October 18, 2000 2:55 PM
Subject: Number of steps per procedure
> I come from the school of thought that says you should limit the number of
> steps in a procedure. The old rule of 7 +/- 2 is usually comfortable to
> I'm flexible - and am ok going up to as many as 10 or 12 steps. However,
> my current project, there are 20+ steps to complete some of the
> The one that prompted this email is actually 19 steps.
> The procedure is done in a wizard-like environment. I know some will say
> that I shouldn't need to document a wizard :) But, it really is NOT a
> wizard. The similarity is that you navigate through the windows from start
> to end, complete many fields along the way. Due to poor design (which is
> supposed to evolve), you really can't jump out in the middle of the
> procedure, nor can you successfully pick up from where you left off.