We recently bought a home appliance. It was something that was going to improve our quality of life substantially so we looked forward to it. Now, after several weeks of use, the device not only meets all our expectations, it even exceeds them. At first, however, we had some frustration at not finding a good and clear explanation of certain functions in the user manual. The manual explained each part, each button and each crank or knob. But it didn’t explain which button, crank or knob to activate, open or close if you wanted to perform a particular function.
Software Application manuals.
The same applies for software application user manuals. Too often still, I read user guides that explain the application and not the processes or tasks that have to be performed with it. They include a detailed description of the menus, functions, buttons, fields and tabs as if they were individual non-interconnected or interrelated entities.
Explain how to hammer a nail in the wall!
If a hammer’s user manual explains that the tool consists of a weighted “head” fixed to a long handle of a specific material, it will give us a true description of the hammer, but will not give us any information on how to use it. Wouldn’t it be more useful for the user to explain how to drive a nail into the wall with the hammer without hitting his or her fingers?
That’s why it’s important to build user manuals around the processes and tasks of the people who are going to use the tool. I know I’m not explaining anything new, but nevertheless descriptive and not active user manuals are still being produced.
In order to write a good user manual, the following tasks must should be carried out beforehand:
- Analyze the process flows elaborated by the operations department. The process flows offer a bird’s eye view of the operations that will be carried out with the tool. Normally they do not break down every task, but give an overview of which department is or will be responsible for which process and how operations are connected. In other words, where the operation of one department ends and that of another begins.
- Analyze the daily tasks carried out by the people or the departments that will use the application. After analyzing the process flows it is time to talk to the people who will translate these processes into concrete tasks. What do they do now and how will they change their tasks using the new tool?
- Analyze application menus and functions. Naturally it is important to know what all the functions, menus, tabs, etc. are. Especially because after having analyzed the process flows and tasks, this knowledge must be translated into a logical manual so that each department can perfectly find the information it needs in the active manual.
Active manuals are manuals that focus on the action rather than the application. Thus, the user manual of an ERP for the logistics department will and has to be different from the user manual for the finance or customer service department, because each department will use the ERP in a different way although sometimes they will use the same menus to perform different tasks.
