Users’ manuals are needed after initial installation and or operation. One of the requirements in the framework is the User Phase. In this stage, users come across a newer situation in the use of the product. All of those must be anticipated and documented in users’ manuals.
The problem is that only a few manufacturers take the time for this detailed analysis and that is why so many annuals either do not solve user problems or fail because they are too hard to learn and use.
So many users’ manuals fall due to the lack of adequate user scenarios. Writers typically create instruction books from specifications and beta interfaces. They document how a product works, but not why it works. They explain how to perform tasks in an interface, but not when a user might need to do those tasks. They describe user options in abstract or generic terms but do not help the user decide which option to choose.
Here is one hypothetical example to support the point. The technical writer has done a very good job of explaining the components of the interface, but nothing about how they relate to users’ real-world problems. The data is described as a developer might understand it, but not in terms of what users need to do with it. As a result, the user guide is essentially useless in teaching what is needed to know to create user training.
A common myth is that user manuals and help are inadequate, that they do not really help people. I think this is the biggest reason why. I see real-world examples and domain knowledge as the missing span in the most user documentation.
That is why I ask this question: When was the last time you learned a new software tool just by reading the user manual or help?
