The rule in minimalist writing that requires you to keep your tasks up to a maximum of seven steps may seem restrictive. In my experience, the procedures that may require more than seven steps are few. In fact, they are usually one-of-a-kind procedures, such as maintenance procedures, installation procedures, and installation procedures. I’m sure others exist, too, but let’s just look at these.
Grouping tasks into maintenance procedures
It is important to remember why we are even concerned about minimalism. Yes, it is easier to read and use, but minimalism also evolved to serve the topic-based author we use to successfully create reusable piles. So, look at from this perspective, go ahead and write your 17-step procedure. Now go back and look at the long procedure:
- Are there any of the steps that describe a task you perform in many maintenance procedures, such as opening a room where maintenance is performed? In this case, write this action as a single topic, Opening the room, and refer to the topic as necessary in all procedures.
- Are some of the steps in this long procedure used in any other maintenance procedure, e.g. A troubleshooting procedure?
For example, let’s say you write a topic about changing the water bottle in an instrument. You must remove and replace the water bottle to perform this procedure and the water bottle is in the aforementioned room. You have instructions for removing the water bottle and also instructions for replacing the water bottle. Even if this procedure was the only procedure for which you remove and replace a water bottle, I would still break these steps out into their own little items. But chances are that these tasks are performed for a myriad of other procedures.
You may also need to remove and replace the water bottle to troubleshoot an air leak or some cleaning procedure involving the water bottle. So it gives you two more reusable items: Removing the water bottle and Water bottle replacement. Don’t forget, you may be able to reuse this information not only elsewhere in your document, but also on another instrument. Having these items as individual piles is what makes recycling possible.
Okay, so now we’ve whittled out the task, which we will definitely reuse, Opening the room, and the reusable steps, Removing the water bottle and Water bottle replacement. What remains are the steps needed to do what you need to do for this water bottle. So you could have a procedure for Cleaning the water bottle. Check the water bottle for leaks. Refill the water bottle. Whatever you do with the poor water bottle is actually between you and your manufacturer. In addition, all these other tasks refer to each topic as needed. E.g:
Cleaning the water bottle
- Open the door of the room. This is a link to Opening the room. (4 steps)
- Remove the water bottle. This is a link to Removing 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 cabin. This is a link to Closes the cabin. (3 steps)
The purpose of all this is to make the 17 step procedure into 3 or more reusable procedures and maybe a few ‘one-of’ procedures. That makes the 7-step goal a little more feasible.
Grouping tasks into installation and installation procedures
Set-up procedures are usually “one-off” procedures. Once the customer / operator / user has configured their system, they rarely visit the area. Installation procedures are definitely ‘one-of’ procedures, because once they are done they never keep their fingers crossed here, they have to be done again.
This does not mean that you cannot or should not feel sorry for the poor person performing these procedures and continue to put them on with your mighty 17-step sections. No! But what should a writer do?
Grouping of installation procedures
Set up procedures are a little easier to group in this regard. It’s about creating some arbitrary groupings that you can write about. For example, with software configuration screens, you can write separate help for each screen. However, some of these screens may be so full of settings that you may need to mentally chunk the information on the screen and then write to these chunks.
I had a screen that I divided into 5 different groups for documentation purposes. This had the added benefit of making the screen parts more searchable in both online help and hard copy indexes. I still had some tasks pushing the 10 stage boundaries, but hey, it was a one-off deal.
Grouping of installation procedures
Installation procedures may be more problematic to group. Some installation instructions only involve placing the DVD in the drive and selecting install. But what if the instrument / device / action you are writing about requires a service person to install it and manage custom configurations along the way. I’m just guessing we could tell the installer that that’s why they get the big bucks. They can give you an argument.
Of course, you would divide the procedures into the different sections of the installation, but it still gives you some sections that appear to require our possible 17 steps. This is where you can use chunking just like chunking, not necessarily with recycling in mind.
You do not have to worry about making each division in an installation an individual topic. This is an ‘off’ and does not need real topic sections. That is unless this installation procedure is similar to many other installation procedures used by all or most of the instruments or applications that you write to. In that case, be sure to create individual topics. It will serve you well.
Imagine the poor Field Service (FS) person, staring down instructions, sharing her attention to see the instrument’s reactions, and needing to go to lunch or the toilet or scratch her nose. This poor person must have logical breaks 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 even slightly change can give hope for the 7 to 10 steps that are optimal.
Another issue to consider is the procedure within a procedure. The simplest example of this is to look at tasks where FS has to restart. Start each of these sections with its title, and then do something similar:
- Log in to the system:
- Enter your username.
- Enter your password.
- Select Login.
- Open the room:
- Locate the door at the back of the instrument.
- Lift the lock up.
- Pull the handle.
- Enter the correct configuration bits for this installation:
Note that you can stiff many steps in such a format. You need to make sure that you do not create an artificial hierarchy. FS personnel are very logical and they will be thrown by an artificial hierarchy and make fun of you behind your back.
Also note that you could write the first step for recycling, Except in this situation. FS staff are not aware of your writing, so they do not care if it is repeated. They also do not want to leave their current place on the page to find the frequently repeated set of instructions. This FS may not even be the same FS person who started the installation if it is a multi-person job. This is where it is very, very important to know your audience, to be empathetic with your audience.
I like step> substep structure illustrated in the example step, but it has a pitfall: some users just don’t have it. This is not usually a problem with FS staff, but in customer procedures some customers may not look past the step to read on to the bottom step. I have witnessed this in use test sessions. The user reads the line “Open the room.” And then say, “I don’t know how to open the room.” In a total violation of the usability testing rules, you will say something directly to the user – in fact, you will scream at them – but the usability coordinator has dropped his mouth.
Use some ingenuity and find out if you can keep your procedures down for 7 steps or at least 10 or less. It will not always be possible, but we live in an imperfect world.