How do you incorporate feedback and revisions into your technical writing process?

Documentation is a product. In the Document Development Lifecycle (DDLC) process, maintenance is an essential step where we instill control points to incorporate feedback into the cycle. Feedback can be for external as well as for internal documentation. The process should have efficient ways of capturing feedback from different roles. The gathered feedback then needs to be analyzed and reviewed for technical accuracy, usability, etc. Next, we implement methods by which feedback can be incorporated conveniently and effectively. This involves taking into consideration the version control systems, authoritative roles etc. A successful documentation process is able to incorporate all of the above into the the DDLC continuously.

Audience is a huge driver of tone. If you’re a freelance writer, ask your client for specific audience demographics. If you’re an employee, reach out to your marketing and sales teams to gain insights in your audience’s needs. In both cases, think about user intent and what you want the ultimate call to action to be.

Getting feedback on your writing can be hard! But ultimately, the goal is to create the best possible end product for your audience. And as you apply that feedback in the future, you’ll have a better sense of how to write for your target audience.

Whenever I interview a subject matter expert, I always run my first draft by him or her for a “tech check” to make sure I understood what was said and captured the technology correctly.

SME's are the technical experts and the owner of the technical content. Usually tech comm responsible only for grammer and punctuation. The feedbacks are important for the quality of the documentation.

Seek feedback early, often, and iteratively to make sure you've understood the technical content and primary audience. Catching problems with early, often, iterative feedback saves time, improves the product, and builds connections with SMEs.

During the initial meeting, my first question relates to the audience of the deliverable. Getting confirmation that I understood correctly the intended message is standard practice for me as the discussion continues. Once the messaging is clear, then the first draft “writes itself,” since the two most important elements are present: knowledge of the audience and understanding of the topic. Then, after an initial review and cleanup, I seek out input and feedback from the subject matter experts and iterate the draft. Depending on the secure status of the document, feedback from others may also be solicited. Feedback is always welcome and taken into consideration.

Technical documents can go for multiple iterations and it is okay. With your first review, you have penned down what you understood from the Product Expert. The second review with the Product Expert will refine the piece with any missed out elements. This time, you have got everything ready on your table. You can reorder sections, add or eliminate steps, add more visuals, flowcharts, and so on. And it's time to test it out with some real users, share it with your focus group or a set of highly engaged users. Gather and analyse their feedback. Well, some times you will have to revisit the content again, refine the content and run a review again. And in other cases, voila! your piece is ready to be published!!