--- title: "Podcast 155: Dealing with Criticism as a Technical Writer" id: "17829" type: "post" slug: "podcast-155-dealing-with-criticism-as-a-technical-writer" published_at: "2025-02-12T08:53:50+00:00" modified_at: "2025-02-12T08:53:50+00:00" url: "https://www.cherryleaf.com/2025/02/podcast-155-dealing-with-criticism-as-a-technical-writer/" markdown_url: "https://www.cherryleaf.com/2025/02/podcast-155-dealing-with-criticism-as-a-technical-writer.md" excerpt: "We’re back from our Christmas pod break with a new episode. We explore the challenges of receiving and responding to criticism as a technical writer. Documentation plays a crucial role in user experience, and receiving feedback- whether constructive or harsh..." taxonomy_category: - "podcast" taxonomy_post_tag: - "podcast" - "Technical Writing" --- We’re back from our Christmas pod break with a new episode. We explore the challenges of receiving and responding to criticism as a technical writer. Documentation plays a crucial role in user experience, and receiving feedback- whether constructive or harsh – can be an opportunity for growth. We discuss practical strategies for handling feedback, evaluating its validity, and implementing improvements to enhance documentation quality. ## Key topics covered - Why receiving feedback (even negative) is better than receiving none - How to separate personal feelings from professional criticism - The importance of acknowledging user feedback and addressing concerns - Types of criticism: Constructive vs. Unconstructive - Methods for evaluating the validity of feedback - Tools and techniques to measure documentation quality (e.g., IBM Quality Matrix, analytics, usability testing) - Addressing common documentation challenges: clarity, findability, audience mismatch, and linking - Steps for implementing improvements and tracking their impact - Preventative measures for reducing future criticism ## Key points - **Criticism is not personal** – It’s about improving the documentation, not attacking the writer. - **Acknowledging feedback** is crucial to building trust and ensuring continuous improvement. - **Evaluating feedback critically** helps differentiate between valid concerns and personal preferences. - **Quality measurement techniques** (analytics, support ticket trends, usability testing) can validate feedback. - **Structured improvements** through linking, clearer writing, audience targeting, and prioritization can make a big impact. - **Continuous monitoring** is necessary to ensure long-term effectiveness. ## Mentioned resources - IBM Quality Matrix for documentation assessment - “Every Page is Page One” by Mark Baker ## Want help improving your documentation? Cherryleaf specialises in fixing developer portals and technical documentation. If you’re struggling with user feedback, contact us for expert guidance. ## Transcript This is the Cherryleaf Podcast. Hello, and welcome to the Cherryleaf Podcast. This is our first podcast in 2025. In this episode, we’re going to look at the topic of dealing with criticism. When you’re a technical writer or a technical author, you develop documentation and receive feedback stating that the documentation isn’t good – that there are problems with it. If you speak to most technical authors, they will tell you that this is something they have experienced, and it can be difficult. You put your heart and soul into creating clear, concise, and helpful documentation, only to receive feedback stating that the information is unclear, confusing, hard to find, or even useless. So, how do you deal with these situations? What do you do when you receive this type of feedback? First, any feedback – good or bad – should not be taken personally. The criticism is directed at the documentation, not the individual. Within the Government Digital Service, when they review content, one philosophy they follow is that everyone did the best they could with the time, resources, and information available at that time. That may well be true in your situation as well. It’s important to respond to critical feedback by acknowledging the concerns and appreciating the time taken to provide it. You need to recognise the user’s experience and thank them for their input. From there, your response can vary. You can acknowledge their input and state that it will be used to improve the documentation, or you can work to specifically address the problems they have highlighted for a quicker and more immediate remedy. Let’s start with the positive: feedback is useful. In many ways, it’s better to receive feedback – good or bad – than to receive none at all. Without feedback, you won’t know if a problem exists, and if a problem does exist, you won’t be able to solve it. Feedback is an essential part of creating effective documentation. You need to carefully listen to or read the feedback and try to understand the user’s perspective. Acknowledge the feedback, thank the user for their time, and recognise their frustration. A good place to start is to evaluate the validity of the criticism. There are different types of criticism – some constructive and some unconstructive. Examine the feedback: is it specific and actionable? Does the user provide concrete examples of where the documentation falls short? For example, do they point out missing or incorrect steps? Or is the feedback vague and emotional, such as simply saying, “It’s useless,” without any direction on how to fix it? Is the feedback a personal opinion, and is that opinion representative of the majority of users? Sometimes, criticism revolves around language choices – such as whether contractions should be used, whether simple phrases should be preferred, or whether buzzwords should be included or avoided. Another consideration is whether the criticism pertains to the scope of the documentation. The user might say, “The documentation doesn’t teach me how to solve a problem,” when that was never the intended purpose of the documentation. Does the feedback align with analytical data? Can you examine support call records to determine if others are experiencing similar issues? Can you assess whether your documentation is effectively reducing support requests? Can you reproduce the user’s problem? Can you follow their steps and experience the same difficulties? Can you identify a root cause? Is the issue a lack of clarity, missing information, poor organization, or something else? Are there patterns in the feedback? If multiple users report the same issue, it likely needs urgent attention. One common problem is documentation quality. There are different measures to evaluate this, such as the IBM Quality Matrix, which provides a checklist for assessing documentation based on different criteria. You can use a spreadsheet with a red-amber-green traffic light system to prioritise issues. Quality assessment criteria include: - Clarity and conciseness: Is the documentation overly verbose or complex? - Completeness: Are important tasks or features missing? - Tone and style: Is the tone appropriate – neither too technical and intimidating nor overly friendly and casual? - Accuracy and currency: Does the documentation reflect the current version of the product? - Findability: Is the information well-organised, indexed, and easy to locate? Another way to validate feedback is by gathering data. This could include analytics on documentation usage, support tickets, and common user issues. Some websites feature feedback mechanisms, such as thumbs-up/thumbs-down icons or forms for users to provide comments. Usability testing tools can track mouse movements and interactions to identify pain points. You should also assess the intended audience. Is there a mismatch between the documentation’s intended audience and those providing feedback? A common issue is content that doesn’t match the skill level of its users. If you’re writing developer documentation, for example, product managers might review it to decide whether to invest in an API. In such cases, the documentation needs to guide them on the API’s benefits and importance. Related to this is the “Every Page is Page One” concept, from a book by Mark Baker. Many users arrive at documentation via search engines, landing on a specific page rather than starting at the beginning. If that page lacks context or assumes prior knowledge, new users may struggle. A solution is to provide internal links to related topics, as seen on Wikipedia. One challenge for technical writers is information silos. Documentation, training materials, support articles, and developer guides may be created by different teams using separate platforms. Consequently, search functionality may be limited to specific repositories. This fragmentation can lead to user complaints that crucial information is missing when, in reality, it exists elsewhere. To address this, technical writers should maintain an index of available content, including descriptions of what each resource covers, its intended audience, and its purpose. By linking relevant materials, you can guide users to helpful content beyond your immediate documentation. Once you identify an issue, the next step is to fix it. Solutions include: - Writing new content - Improving existing content - Adding internal links - Breaking complex topics into smaller steps - Incorporating more visuals - Converting passive voice into active voice You may end up with a long list of required improvements. Prioritisation is key. Using a spreadsheet with a red-amber-green system can help focus on the most critical issues first. Since you likely can’t fix everything at once, set realistic deadlines for each task. A structured plan also allows you to communicate updates to users who provided feedback, informing them that their concerns are being addressed and when they can expect changes. After implementing changes, track their impact. Did the problem resolve, or are users still encountering the same issue? Finally, consider ways to prevent similar issues in the future. Depending on the problem, solutions might include: - Researching your target audience to ensure content is tailored appropriately - Establishing style guides and templates to standardise writing - Enhancing findability through better information architecture - Regularly reviewing analytics and usability data To summarise: criticism isn’t a personal attack; it’s an opportunity to improve documentation. Common issues often involve navigation, clarity, and audience alignment. Having a structured plan prevents feeling overwhelmed by necessary changes. Many fixes are relatively simple yet significantly improve user experience. At Cherryleaf, we help improve developer portals and technical documentation. If you need assistance, feel free to contact us at info at Cherryleaf.com. On a final note, this recording was made using a new tool with enhanced noise reduction. Typically, we use Audacity, but this time we experimented with TechSmith’s Audiate. This tool generates a text transcript, allowing us to edit audio by modifying the text. If you notice any differences, we’d love to hear your feedback – just email us at the same address. ### Share this: - [Share on Facebook (Opens in new window) Facebook](https://www.cherryleaf.com/2025/02/podcast-155-dealing-with-criticism-as-a-technical-writer/?share=facebook) - [Share on LinkedIn (Opens in new window) LinkedIn](https://www.cherryleaf.com/2025/02/podcast-155-dealing-with-criticism-as-a-technical-writer/?share=linkedin) - [Share on WhatsApp (Opens in new window) WhatsApp](https://www.cherryleaf.com/2025/02/podcast-155-dealing-with-criticism-as-a-technical-writer/?share=jetpack-whatsapp) - [Share on Bluesky (Opens in new window) Bluesky](https://www.cherryleaf.com/2025/02/podcast-155-dealing-with-criticism-as-a-technical-writer/?share=bluesky) - ### *Related* ### Leave a Reply[Cancel reply](/2025/02/podcast-155-dealing-with-criticism-as-a-technical-writer/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) #### Previous post [Why AI has meant more work for us as Technical Writers](https://www.cherryleaf.com/2025/01/why-ai-has-meant-more-work-for-us-as-technical-writers/) #### Next post [Cherryleaf’s Technical Author Training Course Reaccredited by the ISTC](https://www.cherryleaf.com/2025/02/cherryleafs-technical-author-training-course-reaccredited-by-the-istc/) #### Browse posts by month Browse posts by month Select Month August 2026 (5) July 2026 (7) June 2026 (14) May 2026 (8) April 2026 (6) March 2026 (14) February 2026 (9) January 2026 (9) December 2025 (7) November 2025 (9) October 2025 (10) September 2025 (7) August 2025 (6) July 2025 (1) June 2025 (3) May 2025 (2) April 2025 (5) March 2025 (3) February 2025 (3) January 2025 (2) November 2024 (8) October 2024 (3) September 2024 (2) August 2024 (3) July 2024 (4) June 2024 (1) May 2024 (2) April 2024 (4) March 2024 (1) February 2024 (2) January 2024 (1) December 2023 (2) November 2023 (9) October 2023 (8) September 2023 (5) August 2023 (3) July 2023 (1) June 2023 (1) May 2023 (2) April 2023 (3) March 2023 (2) January 2023 (2) December 2022 (4) November 2022 (1) October 2022 (1) September 2022 (1) August 2022 (1) July 2022 (1) June 2022 (1) May 2022 (2) April 2022 (1) March 2022 (1) February 2022 (1) January 2022 (2) December 2021 (1) November 2021 (2) October 2021 (1) August 2021 (1) July 2021 (2) June 2021 (3) May 2021 (5) April 2021 (3) March 2021 (3) February 2021 (1) January 2021 (2) December 2020 (4) November 2020 (4) August 2020 (3) February 2020 (3) January 2020 (1) November 2019 (3) October 2019 (1) September 2019 (1) August 2019 (3) July 2019 (2) June 2019 (3) May 2019 (4) April 2019 (1) November 2018 (2) October 2018 (1) July 2018 (2) June 2018 (4) May 2018 (2) April 2018 (3) March 2018 (4) February 2018 (2) January 2018 (3) December 2017 (2) October 2017 (3) September 2017 (1) August 2017 (3) July 2017 (2) June 2017 (7) May 2017 (4) April 2017 (5) March 2017 (1) February 2017 (7) January 2017 (1) December 2016 (3) November 2016 (4) October 2016 (1) September 2016 (5) July 2016 (1) June 2016 (3) May 2016 (1) April 2016 (2) February 2016 (2) January 2016 (5) December 2015 (1) November 2015 (4) October 2015 (2) August 2015 (1) July 2015 (1) June 2015 (2) May 2015 (3) February 2015 (2) January 2015 (6) December 2014 (1) October 2014 (1) September 2014 (4) June 2014 (4) May 2014 (1) April 2014 (2) March 2014 (3) February 2014 (4) January 2014 (4) November 2013 (2) October 2013 (5) September 2013 (3) July 2013 (3) June 2013 (11) May 2013 (4) April 2013 (6) March 2013 (7) February 2013 (4) January 2013 (4) December 2012 (9) November 2012 (23) October 2012 (14) September 2012 (8) August 2012 (4) July 2012 (12) June 2012 (12) May 2012 (10) April 2012 (8) March 2012 (12) February 2012 (3) January 2012 (6) December 2011 (2) October 2011 (3) August 2011 (1) June 2011 (5) May 2011 (2) April 2011 (1) January 2011 (1) December 2010 (1) November 2010 (3) October 2010 (4) September 2010 (8) August 2010 (5) May 2010 (2) April 2010 (3) March 2010 (3) February 2010 (2) January 2010 (3) December 2009 (2) November 2009 (6) September 2009 (1) July 2009 (6) June 2009 (7) April 2009 (8) March 2009 (3) February 2009 (3) January 2009 (3) December 2008 (1) November 2008 (3) October 2008 (3) September 2008 (4) August 2008 (1) July 2008 (3) June 2008 (5) May 2008 (2) April 2008 (2) March 2008 (3) February 2008 (2) January 2008 (1) November 2007 (3) October 2007 (2) September 2007 (1) July 2007 (3) November 2006 (1) October 2006 (2) September 2006 (3) August 2006 (1) April 2006 (1) March 2006 (3) #### Browse posts by category