Give somebody a hammer and everything looks like a nail. Give a technical writer a problem and they’ll more often than not, write an article.
It’s a natural reaction. We just believe that people make mistakes because they don’t know something. We also believe that people read manuals before they attempt to do something. This despite none of us ever exhibiting such behavior in our own lives.
A truth that every technical writer needs to internalize – nobody reads the documentation first.
Let me illustrate. The module is an employee management system. When an employee joins the company, the owner or manager creates a new record. Simple enough. Open the application, go to the Employee module, click Add, enter the employee’s details, and then save. Do they read the documentation to complete the task? No. So what happens when the employee leaves the organization? It’s natural that the owner or manager opens the application, goes to the Employee module, and then clicks Delete. Do they read the documentation? No.
If the user had taken the trouble to read the documentation, they would know that deleting the employee would result in the loss of all the records associated with that employee. The correct process would be to enter the employee’s last working day.
Now you can write enough documentation to compete with The Lord of the Rings and you still will not solve the problem.
Documentation is not the solution to bad product design; it was never meant to be.
So why do people think it is? Product managers, customer success teams, support teams, everyone believes that documentation is the solution. Why?
To understand this really strange behavior, one needs to go back to the moment when the product signed up its first customer. Typically, the PM or the team implementing the product provides the customer with instructions to complete tasks. First over emails, then as Word documents, and finally as a PDF. The system works perfectly.
In the early days of the product, documentation is the hero. It allows users to use and complete tasks in a half-baked, and in-development product. Everybody learns the same lesson – documentation solves all problems.
This behavior becomes organization knowledge. It gets embedded deep within the culture of the company – even when they have over 1000 customers.
Just as HR policies must keep pace with the size of the company, so too must documentation. But it is an inversely proportional relationship. As the product matures and the number of customers grows, the dependency on documentation must reduce – drastically.
Comments