RE: Number of steps per procedure

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.


> 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

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.'


Brent Jones
brent -dot- jones -at- level3 -dot- com

Previous by Author: RE: What do we call this button?
Next by Author: procedures run amok [was Testing Procedures]
Previous by Thread: RE: Number of steps per procedure
Next by Thread: Re: Number of steps per procedure

What this post helpful? Share it with friends and colleagues:

Sponsored Ads