Don’t worry. You’re not alone. The documentation of processes often turns out to be the biggest hurdle for any business that grows quickly.

The best solution: Approach every procedure as a job aid.

To elaborate, designing your procedures as job aids means providing just the right amount of task guidance and support to users so that they can complete the job!

We recommend following this simple approach when reviewing process:

1. Focus on workflow, context, and job role

It is important to focus on the job role NOT the systems.

• Visualize who is doing the work and how content should be structured to help them get the job done.
• If the reader has a technical background, you can omit some of the details that they already know (e.g. how to ping an IP address).
• Focus attention on the overall process and any “gotchas” they might encounter along the way.

2. Use lots of examples

Examples are an important part of this approach. They will be the parts that the reader remembers most.

• The examples have to be relevant. If they aren’t relevant, the reader will have to exert extra mental effort to relate them to the procedure.
• Make your examples as visual as possible, through the use of screenshots and other visual aids. Screenshots make writing a little easier. You don’t have to document every screen detail and mouse click if your screenshots provide enough context.

3. Make it easily accessible

If the document is too hard to find, it probably won’t be used. Make sure that it can be easily accessed.

4. Use a visual mapping approach

Often using visual process mapping can help identify what parts of a procedure are not working.

This is an example of how the IT Glue team has used visual diagrams for its Blueprints

1. Start by bringing the process into a visual format to show who does what and in what order.
2. Think about each step. Make sure that “step 1” really is the first step, if there are presteps that are not completely obvious you need to include them so that following the instructions will go as expected. You shouldn’t get to step 4 and see an error message because they forgot to open a port on a firewall.
3. Don’t get too detailed. The idea is to visualize the steps and then expand on these details in a written procedure once you know how it all works together as one end-to-end process.

Processes are meant to be high level. Our best advice for creating them is to think about how you would explain the end-to-end process to a customer. Taking the customer’s perspective also gives you the opportunity to think about how well the process is working for the customer and make changes.

The post Fixing a Broken Procedure appeared first on IT Glue.