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:Brent -dot- Jones -at- Level3 -dot- com To:tesweeney -at- novadigm -dot- com, techwr-l -at- lists -dot- raycomm -dot- com Date:Wed, 18 Oct 2000 15:49:02 -0600
Tara English-Sweeney wrote on Wednesday, October 18, 2000 1:55 PM:
> 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 me.
> I'm flexible - and am ok going up to as many as 10 or 12
> steps. However, in
> my current project, there are 20+ steps to complete some of
> the procedures.
> The one that prompted this email is actually 19 steps.
[deletia]
> My questions to all of you TECHWHIRLERs are:
> - What do you think about a procedure that has 19 steps?
> - Do you limit the number of steps in a procedure?
> - If so, how do you handle it in a situation that seems
> unavoidable?
> - And, any other thoughts on this situation.
I think your 19-step length is fine. A procedure should have as many steps
as there are discrete actions in the task. The 7 +/- 2 rule is based on some
misapplied cognitive research (see Geoff Hart's discussion of it in his
excellent article at http://www.raycomm.com/techwhirl/tenmyths.html).
Some tasks, by there very nature, have a large number of steps. You can't
force reality into a 7 +/- 2 world. System administration tasks come to
mind. Especially in the *nix world, installation and configuration
procedures can number in the tens of steps, and there is nothing inherently
bad about this. An arbitrary statement that 'procedures should be short' is
about as useful as a statement that 'docs should be short.' a procedure,
like a document, should be just long enough to enable the user to complete
the targetted task(s) with no muss and no fuss. If that requires fifty steps
or 400 page docs, then so be it.
That said, however, lengthy procedures (or documents, for that matter) can
provide an indication that the product being documented might have some
usability problems. Note that I'm not saying that a long procedure always
equals bad software design. I'm just saying that the necessity for long
procedures sometimes arises from bad software design.
My philosophy on issues like this is 'stamp out blanket statements; they're
always wrong.'
cheers,
brent
--
Brent Jones
brent -dot- jones -at- level3 -dot- com
