
I finally checked off an item that had been on my list for far too long: reading the 2025 edition of GitBook’s State of Docs Report, which highlights trends in technical documentation and offers insight into how organizations think about documentation today. My first conclusion is simple: our profession needs more reports like this. Data-driven analysis is essential for helping technical writers advocate for resources, articulate value, and influence product strategy.
The report is organized into five major categories, summarized in the table below:
| Category | Description |
|---|---|
| Purchase decisions and business impact | How documentation affects buying decisions, adoption, and customer satisfaction |
| Documentation team structures | How organizations resource and organize their documentation teams |
| Documentation tooling and API docs | How teams create and maintain API documentation |
| Documentation metrics and measurement | How organizations measure and demonstrate documentation value |
| AI and the future of documentation | How emerging technologies are shaping authoring and content delivery |
The two categories that stood out most to me were Documentation metrics and measurement and AI and the future of documentation. As an industry, we have debated for years how to measure documentation value, and this report advances that conversation. The rapid growth of large language models continues to reshape how knowledge workers function, including those in technical writing. Many outside the profession assume writing can be automated. That has not been my experience. LLMs can assist with certain tasks, but they cannot replace the depth, contextual awareness, or judgment that technical writing requires.
My goal with this analysis is to help busy writers who may not make time to read the full report. I reviewed each section, selected my top three insights, and added commentary to encourage informed discussion across the technical writing community.
Summary of the Report
Full report available here: 2025 edition of GitBook’s State of Docs Report
Before diving into my analysis, it is important to ground the discussion in the data behind the report. GitBook provides clear information about who participated, what questions were asked, and how responses were distributed across roles, regions, and company sizes. Below is a summary of the 2025 State of Docs Report. All data points come directly from the official site.
Key Facts from State of the Docs 2025
- 444 respondents representing multiple disciplines and roles
- 46 questions covering topics such as team structure, workflows, metrics, and AI
- Responses from technical writers, engineers, product managers, designers, marketers, and developer advocates
- Report includes interviews with writers and stakeholders whose quotes appear throughout
- Top respondent roles: technical communication (33.1 percent), leadership (22.3 percent), engineering (18.3 percent), developer relations (5.6 percent)
- Company size distribution from the report’s chart: 50 percent from companies with 0 to 50 employees, 22.1 percent from companies with 51 to 300 employees, 27.9 percent from companies with 301 or more employees
- Primary regions: Northern Europe and the Middle East (39.4%) and North America (35.4%)
- Respondents represent a broad set of professionals who produce, maintain, or rely on documentation. Future editions would benefit from greater representation from product managers, who help shape documentation priorities.
This range of respondents reflects the diversity of professionals who create, maintain, and rely on documentation. In future editions, it would be valuable to see more participation from product managers, who often play a key role in setting documentation priorities and aligning them with product strategy.
1. Purchase Decisions and Business Impact
This section highlights the connection between documentation and revenue. Documentation is often treated as a support function, but the data shows that it plays a front-line role in adoption and conversion.
-
“90% of professionals say documentation is important when deciding to buy a product or service.”
This finding confirms that documentation influences product evaluation. For new or lesser-known products, documentation may be the most reliable information available, especially when search engines and LLMs lack indexed data. Good documentation enables prospects to self-serve. They can evaluate capabilities, verify assumptions, and explore integrations without opening support tickets. Documentation reduces friction during evaluation and accelerates adoption.
-
“Only 35% believe their own documentation influences conversions, revealing a major opportunity gap.”
This perception gap demonstrates that organizations undervalue the business impact of documentation. If ninety percent of people rely on documentation when making buying decisions, but only a third believe their docs influence conversions, then teams are missing critical opportunities. In my consulting work, I saw this firsthand. One client noticed strong correlations between documentation engagement and increased sales. Prospects revisited the documentation several times before purchasing. That insight led leadership to invest more heavily in documentation improvements. This gap is not caused by lack of value. It is caused by lack of measurement.
-
“Many companies fail to use documentation strategically, missing opportunities to connect it to lead generation, retention, and revenue.”
Documentation portals attract high-intent visitors who want to understand the product. They are evaluating features, inspecting APIs, scoping integrations, or preparing for onboarding. When documentation includes calls to action such as free trials, newsletters, or demo requests, technical writing leaders can collaborate with product and marketing teams to create KPIs such as:
- Leads generated from documentation pages
- Trial signups attributed to docs traffic
- Conversion rates from documentation sessions
2. Documentation Team Structure
This section examines how documentation teams scale, where they encounter bottlenecks, and how organizational structure influences content quality.
-
“As organizations grow, documentation debt develops when engineering outpaces writing capacity.”
Most companies employ far more engineers than writers. Ratios like 1 writer to 40 or 50 engineers are not uncommon. As engineering grows, documentation work grows with it. If writing capacity does not keep pace, documentation debt accumulates. This includes outdated content, missing updates, and backlogs of documentation-related support tickets. Documentation debt becomes difficult to resolve because writers must prioritize upcoming releases over revisiting older or incomplete content. A practical solution is to equip documentation leaders with adaptable communication patterns they can apply in different organizational contexts. These patterns may include highlighting the impact of outdated content on support tickets, onboarding friction, customer confusion, or delays in publishing documentation needed to support a release. The goal is to help teams translate documentation risks into business terms that resonate with their specific stakeholders.
-
“Mid-sized companies are most vulnerable, often underfunding writing roles during periods of rapid growth.”
This finding reflects a pattern common in mid-sized organizations. As engineering teams scale quickly, documentation often does not receive proportional investment. These companies are no longer small enough for informal processes to work, yet not large enough to have established documentation systems or dedicated headcount planning. In this stage, technical writers become stretched thin, and documentation struggles to keep pace with increasing product complexity and customer growth. A practical way for documentation leaders to navigate this environment is to connect documentation gaps to clear operational indicators that other teams already feel. Examples include:
- Support tickets tied to unclear or outdated content
- Longer onboarding cycles for customers or internal teams
- Repetitive questions from sales engineering or customer success
- Writer workload data showing unsustainable release-to-writer ratios
These signals help documentation leaders build a more informed picture of where content gaps affect teams, which in turn helps them prepare thoughtful conversations about documentation needs as the company expands.
-
“High-performing teams include writers early in the product development process so documentation can inform, rather than follow, product design.”
Early involvement leads to clearer products and stronger documentation because it allows writers to catch issues while design and engineering decisions are still flexible. When writers join early discussions, teams identify specific problems such as unclear terminology, missing user flows, confusing steps, or overlooked prerequisites. Research in product development confirms that early involvement of user-facing roles reduces usability issues and decreases downstream rework. (Source: RIKON Group, 2017) I have seen this repeatedly in practice. When writers participate early, the product’s user experience improves, and the documentation produced later feels more accurate, integrated, and aligned with how users will actually interact with the system.
3. Documentation Tooling and API Docs
This section reveals the challenges teams face in maintaining accurate, scalable API documentation and the shift toward more interactive developer experiences.
-
“56% cite ‘keeping API documentation up to date’ as their top challenge because manual updates cannot keep up with product velocity.”
Rapid release cycles make manual updates difficult. Inconsistent workflows, lack of integration with engineering systems, and insufficient automation create documentation bottlenecks. I would love to see future editions include interviews with technical writing managers on how they manage documentation challenges as engineering teams grow. Hearing how others navigate these scaling pressures could give documentation leaders valuable insights into quantifying resource needs and advocating for support within their own organizations.
-
“74% of API teams use OpenAPI, signaling maturity in structured, spec-driven documentation.”
OpenAPI adoption has become widespread, which shows strong industry alignment around structured, machine-readable API specifications. However, adopting OpenAPI does not automatically translate into smoother documentation workflows. Many teams generate accurate specs but still struggle to connect those specifications to their publishing processes, resulting in delays between updates to the API and updates to the published documentation. In many organizations, the challenge is not the spec itself but the gap between where the specification lives and how documentation is built and maintained. Closing this gap often comes down to clearer ownership and tighter coordination between engineering and documentation teams. When both teams align on workflow expectations, review processes, and release timing, OpenAPI is far more likely to serve as a reliable source of truth that flows cleanly into published documentation.
-
“Teams want interactive, automated documentation with features like ‘Try it out,’ live previews, and real-time updates, reflecting a shift toward treating documentation as part of the product.”
Developer expectations have evolved. While static reference documentation remains essential for concepts and deep explanations, modern API users increasingly expect interactive examples, executable code blocks, and integrated testing environments that reduce the need to switch tools while learning an API. Tools such as Swagger UI, Redoc, and sandbox-style environments demonstrate this shift by consuming an OpenAPI specification to generate interactive consoles. When implemented well, these experiences can meaningfully improve developer onboarding by:
- Reducing the time it takes for a developer to make their first successful API call
- Lowering support volume by helping developers troubleshoot problems directly in the browser
Achieving this level of developer experience requires more than adding a “Try it out” button. It depends on tight coordination between engineering, product, and documentation teams so that the specification, the implementation, and the published documentation stay aligned. Organizations that treat the API and its documentation as a co-released product tend to create smoother onboarding experiences and fewer gaps between what the API does and what the documentation describes.
4. Documentation Metrics and Measurement
The report highlights a familiar challenge. Documentation is widely recognized as important but remains poorly measured across many organizations.
-
“Smaller teams are more likely to link documentation to lead generation, suggesting agility helps in tracking ROI.”
Smaller teams can experiment more easily because they do not face the lengthy approval cycles that are common in larger organizations. They can test call-to-action placements, add lightweight analytics, and adjust quickly based on results. In larger organizations, the challenge is often coordination. Documentation spans engineering, product, marketing, and support, which means no single team owns the full analytics picture. Because measurement is spread across multiple functions, documentation’s contribution to lead generation or product adoption can be difficult to quantify.
-
“Successful teams use both quantitative (traffic, leads) and qualitative (feedback, satisfaction) data to measure impact.”
Using both types of data creates a clearer view of how documentation performs. Quantitative metrics show what users do, while qualitative insights explain why they behave that way. For example:
- High time on page may indicate confusion rather than engagement
- Low search success may signal terminology or information architecture issues
- Repeated support tickets can reveal unclear instructions or missing steps
Teams that combine behavioral data with user feedback tend to make more accurate improvements. They also avoid relying on vanity metrics and instead focus on indicators that better reflect user success and documentation quality.
-
“The key barrier is not awareness; it is tooling and time. Most teams lack the systems or bandwidth to connect documentation to business outcomes.”
Documentation analytics are often scattered across tools such as Google Analytics, search logs, support platforms, and content management dashboards. This fragmentation makes it hard to understand how documentation influences adoption, onboarding, or retention. The challenge is not gathering data, it is connecting that data in a meaningful way. A practical step forward is to integrate documentation events into existing product analytics tools rather than building separate systems. This helps teams correlate documentation behavior with real product usage and business outcomes without introducing new processes or additional platforms.
5. AI and the Future of Documentation
AI is transforming documentation workflows. It accelerates drafting and editing while unlocking new content delivery models. However, human expertise remains essential for ensuring accuracy, nuance, and trust.
-
“60% of teams already use generative AI in documentation workflows, and 42% believe AI will create adaptive, user-personalized documentation.”
AI is becoming a routine part of content pipelines, particularly for drafting, summarizing changes, and producing variations tailored to different audiences or contexts. These efficiency gains allow teams to focus on higher-level work, but they also carry potential risks. For instance, research from AI and Society highlights that the rise of AI can create ‘capacity-hostile environments’ that deskill human workers. For technical writers, skills like understanding real user needs, structuring content, and making nuanced editorial decisions remain essential. When used thoughtfully, AI can accelerate production without diminishing these critical abilities; however, uncritical reliance on AI risks eroding precisely the skills that make technical writers valuable.
-
“AI assists most with drafting, editing, and summarization, freeing writers to focus on structure, quality, and strategy.”
This aligns with both industry practice and personal experience. AI reduces the time spent on early-stage writing and repetitive tasks, but it does not replace the responsibilities that require human judgment. Writers still determine information architecture, validate technical accuracy with engineers, interpret user intent, and ensure that content reflects product behavior and organizational voice. AI increases capacity, but it does not replace:
- content strategy
- cross-functional collaboration
- user advocacy
- domain expertise
- long-term maintenance thinking
Teams that lean on AI for speed while strengthening these human-led activities see the strongest results.
-
“Documentation is evolving into dynamic, point-of-need experiences that include embedded tooltips, chatbots, and contextual help.”
The report highlights a growing shift toward delivering answers where users already are. This trend reflects broader product expectations: users want guidance inside the interface, not through long-form content alone. Interactive help systems reduce context switching, shorten troubleshooting time, and surface the most relevant answers based on what the user is doing. AI enhances this shift by powering chatbots, guided flows, and adaptive content models. These systems generate data that documentation teams can use to identify gaps, refine search, and better understand what users struggle with. The opportunity is not just technological, it is strategic. Documentation teams will increasingly collaborate with UX and product teams to design these embedded experiences.
Closing Thoughts
GitBook’s State of Docs Report is a meaningful contribution to the profession. It shows that documentation leaders, writers, and product teams are beginning to converge around shared challenges: measurement, AI adoption, content quality, and cross-functional collaboration.
If technical writing is going to earn broader recognition within organizations, the field needs clearer ways to articulate value. Metrics tied to adoption, onboarding success, and support reduction can help demonstrate documentation’s business impact and strengthen the case for investment.
A dedicated industry summit focused on documentation measurement standards could accelerate this progress. Potential outcomes might include:
- Recommended KPIs for documentation effectiveness
- Guidelines for responsible AI use in documentation teams
- Strategies for preventing writer deskilling
- Benchmarks for team composition and workload capacity
At the same time, technical writers should continue developing capabilities that AI cannot replicate reliably. These include contextual reasoning, user empathy, stakeholder collaboration, domain expertise, and information architecture. Research validates that these human skills remain essential, even as automation becomes more widespread.
With shared frameworks, stronger community engagement, and responsible AI adoption, the field is well positioned to elevate the impact of documentation across the technology industry.
Sources and Further Reading
Primary Report
- GitBook: State of Docs 2025. https://www.stateofdocs.com/2025
AI and Deskilling
-
AI deskilling is a structural problem:
https://link.springer.com/article/10.1007/s00146-025-02686-z
Developer Documentation and Industry Resources
- GitHub Octoverse Documentation Summary (2021 PDF): https://octoverse.github.com/2021/static/octoverse-report-2021.pdf
- GitHub Octoverse 2021 Archived Full Report: https://web.archive.org/web/20211117210129/https://octoverse.github.com/creating-documentation
- Good Docs Project Fact Pack: https://docs.google.com/presentation/d/1fZqNm7WH1hYgmjuq2lkltbfTZYDZeclpuaoLabjihJ8/edit
- Agile Documentation: Writer to Developer Ratio Reference: https://www.agiledocumentation.co.uk/2016/04/what-is-optimal-writerdeveloper-ratio.html
- Connecting Technical Communication to Sales: https://www.thecontentwrangler.com/p/connecting-technical-communication
- Developer Documentation Survey 2020 (Tom Johnson): https://idratherbewriting.com/blog/developer-documentation-survey-2020/