Good procedures: reducing complexity

man wearing black and white stripe shirt looking at white printer papers on the wall

In previous posts, I’ve talked about the different kinds of procedures and how to write about task paths for your users. Now let’s look at how to structure tasks in standard operating procedures.

We’ve all looked at a set of standard operating procedures with 100 steps. Early in my career, I wrote those. I didn’t know better. But long procedures like that are so bad to do to your users. Just looking at that many steps makes you tired.

good procedures, write good procedures, how to write good procedures, knowledge base writing, writing steps, how to write good steps, write procedures, technical writing procedures, how to write a good standard operating procedure, how to write a good procedure, information architecture, content strategy, how to write good policies and procedures,  standard operating procedures, writing  standard operating procedures

These tips can help you even if you’re not writing long, complex procedures in your knowledge base articles or help systems. You can write good procedures, even when they really need to be long.

100 steps of procedural death

No one wants to follow 100 steps. There’s nothing about a list of 100 steps that makes anyone want to do that standard operating procedure.

So they won’t.

At best, they’ll come up with their own methods to accomplish that task or, at worst, they simply won’t do the task in any way. This can have serious business impacts because that can mean an important business process simply doesn’t get done. The cognitive load for that many steps is too high.

So how do we solve this? How do we write good standard operating procedures that people can use?

10 or fewer steps

The total number of steps in any chunk needs to fit in the readers’ cognitive load. Because we have little control over the cognitive load our readers come to us with, we take actions to decrease the additional load we place on them. That’s all we have.

Fewer than 10 steps helps reduce that load a lot. Research shows people can keep 3 to 5 items in working memory at any 1 time and act on it. So let’s leverage that. Let’s use that in a first pass as we write standard operating procedures.

Here’s the example procedure we’ll work with in this post (you’ve seen a version of this before in another post about procedures):

  1. Using your company username and password, go to [pretendURLlinkhere] and log into the BlobBlob system.
  2. From the menu on the left, click Request Time off.
    (A screen capture here would be great, including the items for step 3 and 5 circled or boxed.)
  3. Near the top of the page, click the Start date calendar icon.
  4. Select the date you want to start your time off. This is your first full day of vacation.
  5. Click the End date calendar icon.
  6. Select the date to end your time off. This is the last day you want to be away. The end date must be after the start date.
  7. Review the dates to make sure these are the dates you want off.
  8. When you’re ready, click Submit. You see a message on the screen.
  9. Read the message and click OK. You return to the BlobBlob home page.
  10. From the menu on the left, click View pending time off. You see your pending requests.
    (A screen capture here would be great.)
  11. Click the request you just made.
  12. Review the dates to verify they’re correct. Then click Next.
  13. On the next screen, complete the Reason for the request. You can type up to 300 characters, including spaces.
  14. Click Next.
  15. On the next screen, from the Approval list, select the name of your supervisor.
  16. Click OK and then click Next.
  17. On the next screen, verify the information about your request is accurate.
  18. If you need to make changes, click Update.
  19. When you’re satisfied the information is correct, click Save and then click Submit. Your vacation request is sent to your supervisor for approval. You can see approved vacation days on the first screen when you log in.

This procedure is a lot of steps and makes the entire process look hard. Few people can follow these steps and get them done correctly. So let’s start fixing them. We have several options to write good standard operating procedures. We can chunk these steps by:

  • area of the screen,
  • trivial clicks,
  • general subtask,
  • or all of these.

All of these methods in one place

Let’s try all of these ways to chunk the information in 1 example.

  1. Using your company username and password, go to [pretendURLlinkhere] and log into the BlobBlob system.
  2. From the menu on the left, click Request Time off.
    (A screen capture here would be great, including the items for step 3 and 4 circled or boxed.)
  3. Select your vacation start date. Do the following:
    • Near the top of the page, click the Start date calendar icon.
    • Select the date you want to start your time off. This is your first full day of vacation.
  4. Select your vacation end date. Do the following:
    • Click the End date calendar icon.
    • Select the date to end your time off. This is the last day you want to be away. The end date must be after the start date.
  5. Confirm these dates are correct:
    • Review the dates to make sure these are the dates you want off.
    • When you’re ready, click Submit. You see a message on the screen.
  6. Read the message and click OK. You return to the BlobBlob home page.

This groups and chunks the procedure steps by general task, and then by area of the screen, and then by trivial clicks in the same area. Additionally, we also layer the information in the steps to account for sophisticated users and more naive readers. For example, step 3:

Select your vacation start date. Do the following:

allows readers who are more sophisticated (familiar with requesting time off) to read the first sentence and then go do it. They probably don’t need the substeps (indented bullets). Because they’re familiar with requesting time off, they just want the reminder of the steps they need to do.

Our more naive readers (not familiar with requesting time off) read the first sentence. We’ve set the expectation of what they’re accomplishing in this step. They can use the substeps to do this part of the process.

We can decide to drop the Do the following: if we like. That’s a style choice. I prefer to keep it because I think it naturally leads to the substeps. But if we were translating to multiple languages, I may recommend we drop it because words cost money, per language.

Chunking the steps into areas of the UI and into related clicks makes it easier to follow the steps. People can keep these small pieces of information in their working memory while they do the clicks. The clicks are also in the same area of the screen, probably just a few pixels apart.

Guidelines to write good procedures

How do you choose what’s best when you’re looking at writing your complex procedures?

Start by chunking the related clicks. See how far that gets you. You may find you’re also layering the information as you go. Remember, these are both great first steps to clarify your procedures.

Look at what you can group. Good candidates for grouping are items that are:

  • a few pixels apart
  • part of the same labeled area of a screen
  • the same wizard screen

If your reader leaves a screen to continue, for example, you reached the end of the chunk. If the substeps are 5 or more, consider making multiple steps, based on where the reader is on that screen. Remember, working memory can hold 3 to 5 items of information, so the total number of substeps in any step matters.

There’s more to writing good standard operating procedures, and I’ll cover that in a future blog post, so stay tuned.

One response to “Good procedures: reducing complexity”

  1. […] I’ve covered the basics of procedures, how to identify and follow task paths, and how to chunk your procedures to let humans follow them. This post talks about long complex technical procedures in technical […]

Leave a Reply