Technical Documentation Plan

Developing the technical documentation is a three-stage process. Please have a look at the plan explained below.

Stage I: Developing the Documentation Architecture

In this stage, I will complete developing the documentation architecture that will lay out all the modules/categories we will have for the product and the support articles (with titles) that will need to be developed for each of these modules/categories. This architecture will be comprehensive and will cover all the documentations that we need to write.

At this stage, I also recommend the CMS that would best suit the requirements. If a CMS is already in use, then the same shall be used.

Stage II: Developing Documentation Management Sheet

After the approval of the Documentation Architecture, a documentation management sheet will be developed that will work as a single source of truth to review each documentation that has been completed. This sheet will be developed based on the documentation architecture of the product.

A. After completing the documentation, I will drop the link in this sheet for review by the product owner. I will assign the tag - “For Review”.
B. If the document is approved, then the same can be marked as completed. The product owner can add the tag - “Approved”.
C. If the document is not approved, then the comments can be added to the document to execute the changes. In this case, the owner can add the tag - “Need Changes”.
D. After resolving the comments, the product owner can review the document again, mark it as approved, and add the tag - “Approved”.

Stage III: Making the Documentation Live

Once all the support articles/documentation have the tag “Approved”, we will move it to the website and make it available for the users to consume. While making the documentation live, I will be following SEO-friendly practices as well.

Writing Attitude While Developing Documentation

Structuring the documentation and breaking it down into multiple heads for creating a logical flow within. A logical hierarchy and flow need to be established. The transition from one head to another should be clear.
Providing an intent/action at the beginning and how it can help the users is important for every product documentation.
Filling in the outline. A step-by-step approach for simplicity and easy communication. Adding important notes. Adding extra information where necessary.
Adding visuals: images (annotated with primary red color), GIFs, or Loom videos where multiple actions are involved.
Hyperlinking to other articles in the documentation database where appropriate.
Conclusion: A one-line closure at the end of the article where we allow users to connect with the support team if they still have any doubts.

Collecting Product Intelligence and Understanding

To write actionable documentation, it is important to understand the behavior of the product and how different functionalities work. There are various methods to get this done, but I will keep it restricted to the following two:

Method I: Recording Actions in Loom

The product owner can record the operations through a video sharing tool like Loom and explain the logic and steps.

Method II: Self Exploration

The product owner can share access to the QA environment or staging and I will self-explore the platform to raise queries. The product owner can answer them and I can develop the documentation accordingly.