Have you observed the tone in which these products communicate with us? It’s no longer the boring, formal tone. It’s the casual, conversational tone that invites you when you go to their websites, interact with their UI, and so forth.
The user experience is greater than the sum of those parts: your customers judge your product on the entire customer journey. This means that “traditional” documentation needs to fit seamlessly into the customer-facing content produced by your company: marketing material, sales brochures, training programs, and the product’s user interface. We rarely know at which point in their journey a buyer will want to access technical content, so we can’t presume that our docs will only be read after the purchase. Continue reading
When I talk to programmers about what I do, they often ask me why structured writing is important any more. Machines are getting so good at reading human language, they argue, that semantic markup to assist the machine is increasingly becoming pointless. But structured writing is not about assisting the machine. It is about enlisting the machine to assist the writer. And where the writer need assistance most of all is with quality. Continue reading
By inviting the developers and support or sales engineers to update the documentation, we make immediate and direct use of the expertise of our subject matter experts. By inviting product managers and programme managers to assess the documentation requests and help prioritise them before the sprint, we’re making use of their product and customer knowledge too. Continue reading
On a good development team, code is created to be handed off. Developers use best practice techniques, such as Block, Element, Modifier (BEM) syntax, to create clean, maintainable code that can easily be handed off and taken over. While there’s no denying you still have to play with the code to truly understand it, the learning curve isn’t nearly as steep because the person who created the code had you in mind while developing it. Continue reading