API Documentation Project
Discover my gold standard of technical writing, from platform design to doc-as-code implementation on a global scale. Learn about the journey and transformation of the documentation.
Bridging the gap between developers and non-technical users
This project only had myself as the sole architect / builder / content writer and tester for usability behind this extraordinary evolution.
Infrastructure and Tools
Languages and Tools
Major Changes
Key Improvements
- UI Improvements: Enhanced user interface for a better user experience.
- Interactive Portal: Fully functional interactive portal in the New version.
- Doc-as-Code: Integrated documentation directly into the development workflow.
- CI/CD Pipelines: Continuous integration and deployment of documentation.
- Repository Automation: Mapping and automation of multiple repositories.
- Endpoint Testing: In-doc endpoint testing for API functionality.
- Feedback Mechanism: Critical feedback mechanism for continuous improvement.
- AI and Test Automation: Rigorous testing for accuracy and completeness.
Development Journey
Doc-as-Code Implementation
I implemented a Doc-as-Code philosophy to gather information from multiple developer teams regarding the various APIs that make up the overall product. This system was embedded into each of their pipelines so that when they run a CI/CD, the documentation is updated upon release. Configuration files were generated to ensure compliance with OpenAPI standards. The API documentation was split from one large document into smaller, compartmentalized sections for better organization and maintenance.
Enrichment Process
Even though the core data is brought through the pipeline from the SMEs in relation to development, the documentation is subject to an enrichment process that I conduct by actually using the information gathered to initiate the API and mock an integration or actually process QA against it. This forms the foundation of finding the sticking points and liaising with product owners to release as much information as possible without infringing on any company Intellectual Property (IP).
Early Engagement
Processes have also developed where I am integrated into the transition processes of new products early and engage with new products to bed down requirements from all key stakeholders. This has changed the way products are released, meeting all requirements prior to releases. The need to engage SMEs, product owners, and other stakeholders has been made a new process under my watch to allow the application of technical writing to be more focused on applying principles and standards expected rather than just standard content creation, which can be a misconception of the position.