When I began working on this product, only two products existed that could render documentation from an API specification: MuleSoft's API Console and Swagger UI. After evaluating the existing API Console and the closest competitor, Swagger UI, using internal feedback and public forums, I determined the main pain points and decided on the future direction for the product.
The first major decision I made was to separate the API specification parsing process from the documentation rendering. Previously, the console would parse the API specification every time it loaded in the browser, which could take minutes. By generating a view model from the API specification before publishing the documentation, I reduced the load time from several seconds to under a second. While I don't have exact values to share, the improvement was significant.
The second major change I made was to improve how the documentation was rendered. Previously, both Swagger UI and the API Console would display all endpoints on a single page with documentation below it. This proved to be inefficient for complex APIs, taking up to 15 seconds to render in some cases. I solved this by dividing the documentation rendering into separate pages for each endpoint, resulting in rendering times of about a second, which met our budget at the time.
Finally, I built the API Console using web components, allowing it to be embedded in different products and CMSs, even those using different technologies. Additionally, this approach enabled the reuse of API components in different applications, which was a cutting-edge approach to application design and development in 2016.
To improve the user experience, I utilized Google Analytics to measure user interaction with the documentation. I also held multiple sessions with users to gather feedback on their experience using the application. Based on their feedback, I redesigned the navigation to support indentation and search. Additionally, I introduced the option to view all operations within an endpoint at once, instead of just one operation. Lastly, I used their input to streamline the "try it" function, making it easier and faster for users to input data and send HTTP requests.
