The Product is Docs: Writing technical documentation in a product development group
amazon.com
The Product is Docs: Writing technical documentation in a product development group
Working with another author can be a fun way to shake things up, get a second perspective on your work, learn new skills, and uncover style variations between writers for the same product.
For example, you can say in your reply, “If you could give me more information about what you were trying to do and how this topic could be more helpful, I can steer you in the right direction and then I will revise the topic to make it better.”
At Splunk, we’ve introduced the idea of “Agile checklists”—sprintable artifacts we can use to collect relevant information within the scrum process so that writers can use it to develop information that spans multiple sprints or scrum teams.
Make a direct offer to assist where you’re able. People are frustrated because they can’t do something they expect to do easily.
our experience indicates that a useful audience definition works better than a persona for training new writers, applying techniques like learning objectives, guiding broader information design and development questions, and enabling customers to identify what content is relevant to them.
Most of the time, frustrated users want to complete a task or install a product and cannot because the instructions assume a certain level of experience and don’t account for novices, or because the user can’t find the information they need.
A regular customer feedback loop is fundamental to the Agile method. Iterative development without constant customer validation isn’t really Agile.
Every tech writer knows two basic things about our work: We spend only a fraction of our time actually writing. The information development cycle is circular and continuous.
Tell the customer of the action you plan to take and keep them updated throughout the process.