The minimalist writing rule that requires you to keep your tasks to no more than seven steps may seem restrictive. In my experience, procedures that may require more than seven steps are few. In fact, these are often “one-time” procedures, such as maintenance procedures, setup procedures, and installation procedures. I’m sure there are others too, but let’s look at these.
Group tasks into maintenance procedures
It is important to remember why we are even concerned with minimalism. Yes, it is easier to read and use, but minimalism also evolved to serve the theme-based authorship that we use to successfully create reusable snippets. So, viewed from that perspective, go ahead and write your 17-step procedure. Now take a step back and look at that lengthy procedure:
- Do any of the steps describe a task that you perform in many maintenance procedures, such as opening a compartment where maintenance is performed? In that case, write that action as a single topic, Compartment openingand refer to that topic as required in all procedures.
- Are any of the steps in this lengthy procedure used in some other maintenance procedure, such as a troubleshooting procedure?
For example, suppose you are writing a topic on how to change the water bottle on an instrument. You have to remove and replace the water bottle to perform this procedure and the water bottle is in the compartment mentioned above. It has instructions for removing the water bottle as well as instructions for replacing the water bottle. Even if this procedure were the only procedure for which you remove and replace a water bottle, it would still break those steps down into their own little topics. However, these tasks are likely to be performed for a wide variety of other procedures.
You may also need to remove and replace the water bottle to troubleshoot an air leak or some cleaning procedure that involves the water bottle. So that gives you two more reusable themes: Remove the water bottle Y Water bottle replacement. Don’t forget that you may be able to reuse this information not only elsewhere in your document, but on another instrument as well. Having these themes as individual fragments is what makes reuse possible.
Ok, now we have reduced the task that we will definitely reuse, Compartment openingand the steps that can be reused, Remove the water bottle Y Water bottle replacement. What remains are the steps required to do what you need to do with this water bottle. Then you could have a procedure to Clean the water bottle, Checking the water bottle for leaks, Refill the water bottle. Actually, whatever you do to that poor bottle of water is between you and your maker. Also, all these other tasks would refer to each topic separately as needed. For example:
Clean the water bottle
- Open the compartment door. This is a link to Compartment opening. (4 steps)
- Remove the water bottle. This is a link to Remove the water bottle. (5 steps)
- Blah blah clean. (1 step)
- Blah blah dry. (1 step)
- Replace the water bottle. This is a link to Water bottle replacement. (5 steps)
- Close the compartment. This is a link to Close the compartment. (3 steps)
The intent of all of this is to convert the 17-step procedure into 3 or more reusable procedures and perhaps some “one of” procedures. That makes the 7-step goal a little more achievable.
Grouping tasks in the installation and configuration procedures
The setup procedures are usually single procedures. Once the customer / operator / user has set up their system, they rarely visit the area again. The installation procedures are definitely ‘one of’ the procedures because once done they never, keeping your fingers crossed here, have to be done again.
This doesn’t mean that you can’t or shouldn’t feel sorry for the poor person performing these procedures and continue to load them up with your powerful 17-step sections. Not! But what is a writer to do?
Pool configuration procedures
The setup procedures are a bit easier to group in this regard. It’s about creating somewhat arbitrary groupings that you can write about. For example, with the software setup screens, you can write separate help for each screen. However, some of those screens can be so cluttered with settings that you may need to mentally split the information on the screen and then type in those chunks.
I had a screen that I divided into 5 different groups for documentation purposes. This had the added benefit of making parts of the screen easier to search in both the online help and the printed document index. I still had some tasks that went beyond the 10-step limits, but hey, it was a one-time deal.
Group installation procedures
Installation procedures can be more troublesome to bundle. Some installation instructions just involve placing the DVD in the drive and selecting Install on pc. But what if the instrument / device / operation you are writing about requires a service person to install it and manage custom settings on the go? I guess we could tell the installer that’s why they make a lot of money. They could give you a discussion.
Obviously I’d break down the procedures into the different sections of the installation, but that still leaves a few sections that seem to require our possible 17 steps. This is where you can use sharding as sharding, not necessarily taking reuse into account.
You don’t have to worry about turning each division of an installation into an individual theme. This is a ‘one of’ and does not need actual topic divisions. That is unless this installation procedure is similar to many other installation procedures used by all or most of the instruments or applications you are writing for. In that case, go crazy and create individual themes. It will serve you well.
Imagine the poor person in the Field Service (FS), staring at lines of instructions, dividing his attention to observe the responses of the instruments and needing to go to lunch or the bathroom or scratch his nose. This poor person needs to have logical interruptions in the procedure where this can happen without losing his place. Inserting a new heading, still within the section, in a place where the tasks change even a little bit, may offer some hope of the optimal 7-10 steps.
Another trick to consider is the procedure within a procedure. The simplest example of this is looking at the tasks where the FS has to restart again. Start each of those sections with its title and then do something like this:
- Login to the system:
- Please enter your username.
- Enter your password.
- Select Login.
- Open the compartment:
- Locate the door on the back of the instrument.
- Lift the latch.
- Pull down on the handle.
- Enter the correct configuration bits for this installation:
- Etc
Note that you can include many steps in that format. You need to make sure you don’t create an artificial hierarchy. FS staff are very logical and they will be thrown into an artificial hierarchy and made fun of behind your back.
Also note that you can write the first step for reuse EXCEPT in this situation. FS staff are not paying attention to your writing, so they won’t mind if it is repeated. They also don’t want to leave their current place on the page to find that frequently repeating set of instructions. This FS may not even be the same person who started the installation if it is a multi-person job. This is where knowing your audience, empathizing with your audience, is very, very important.
I like the step> substep structure illustrated in the example steps, but it has a problem: some users just don’t understand it. This is generally not an issue with FS staff, but in client procedures some clients cannot see beyond the Step to read the Substep. I have witnessed this in usability testing sessions. The user reads the line “Open the compartment”. And then it says, “I don’t know how to open the compartment.” In a total violation of the usability testing rules, you want to say something directly to the user, you actually want to yell at them, but the usability coordinator has taped your mouth shut.
Use a little ingenuity and find out if you can keep your procedures to 7 steps or at least 10 or less. It won’t always be possible, but we live in an imperfect world.