Copywriter, content marketer and ghostwriter
Copywriter, content marketer and ghostwriter
The best software in the world can fail if nobody knows how to use it. That’s what the documentation is for – but when that documentation is written by your developers, how can you be sure that it’s going to be easily understood and used by users? That was the challenge OxTS faced when launching their generic aiding data (GAD) SDK. The SDK and the interface behind it were a major part of OxTS’ growth strategy, but the documentation was fragmented, disordered, and incomplete. The team knew they needed to fix the documentation – but the marketers were all busy marketing and nobody else understood the product well enough to write documentation.
I was asked to take a look at the documentation and suggest a plan for “fixing it”. I’m quick to understand new things, so I dove straight in to the existing documentation and soon worked out a new structure that would make the information more readily accessible to users. Over a period of months, I rewrote the documentation almost from the ground up, with regular calls between me and the lead developer to make sure I stayed on track and to discuss any questions that came up.
Those sessions not only helped me produce the best documentation possible, but also helped OxTS think more critically about how their SDK worked, and issues we raised during the documentation process became some of the first improvements to the SDK.
The new version also included a key concepts section to aid understanding (after all, inertial navigation is a very technical subject), and a glossary of key terms to help readers keep up. Once it was complete, the master document was kept and dug out for the next phase of the SDK’s development, to ensure that the documentation remained the sole source of truth about the SDK and how it works.