Many tech companies encounter problems when they need to create and expose manuals or tutorials to their customers. This is often because there is no understanding of how manuals should be treated and produced, or even who is responsible for their preparation.
Who has never heard the phrases: “What should the product documents do”; “Every developer should document their application” or worse: “It’s in production, who updates the manuals now?” In the midst of this shifting responsibility, developer manuals, tutorials, and portals end up deteriorating, which is a terrible image for your product/company.
To help anyone with problems like these described, here are 3 practices we recommend to you:
1. Find an owner
A very common problem is who should be in charge of the documents, not as an up-to-date person, but as a person who is responsible for the quality and success of that part of the product.
In some companies, there is the idea that each OO should organize documentation, but some areas and support may also be required to keep manuals up to date and practical.
It is a conflict between the idea of “who specifics” (who understands how the product works at all levels) and “who gets customer feedback” (those who understand and hear the difficulties of those who seek information from the source). This ends up generating a “hot potato” that never gets the attention it needs. After all, between deciding to document something and create a solution, most people prioritize the second option.
One solution is to define a person responsible for the “performance” of the manuals. He is in charge of navigating all the company’s teams, mapping how each product/service creates its manuals and understands the difficulties of the process. This person should analyze how users relate to documents, propose solutions that streamline the update process, and gather feedback to understand how to improve each product’s communication with its target audience.
2. Treat your “documents” as a “product”
In themselves, products exist to deliver value that meets or exceeds a customer’s expectations. Stop to think about what makes a product attractive. There are several factors that can increase and decrease the attractiveness of a product, but for this discussion, we will focus on three variables:
They exceed the value they promise;
Generate usability satisfaction;
They are competitive in the face of competition.
Documents that “outweigh the value they promise” are documents that not only show how to use a tool described but present solutions and ways of use that the customer does not know or imagine possible. Remember that the person reading the document does not always understand the range of solutions or understand the market they are entering, and needs to be “educated” about these possibilities. Always think of this example: The can of condensed milk has instructions for opening, but the differential comes in the recipe printed on the label. Can opening = tool use; Revenue on label = possibility the customer may be unaware of.
Documents that “generate usability satisfaction” are the ones that have a rational reading structure according to the audience that reads it. It’s no use having the most complex manual in the world, whether it’s in a 500-page PDF, or stream detail without a code sample. Gather feedback from users of your documents and their support teams. They will indicate what are the main points of stress in using the documentation.
3. Feedback with metrics
Understand who reads the documentation already has an owner, it has already been reworked and analyzed for better usability and is now fully updated; you still have trouble getting your users and customers to use/understand your products.
This can be due to the difficulty in understanding how readers of your documents think or what questions they actually have. One of the biggest difficulties in assembling these types of documents is putting yourself in the reader’s shoes. After all, those who assemble the manual must have a thorough knowledge of the tool being documented. This knowledge makes the assembler of the manual ignore points that – for the users – are not so simple.
