Inform a medium-sized documentation project with data

Tue, 27 Oct 2026 10:33:00 +0000

If you are about to start a medium-sized documentation project, you can inform each step of the process with data. If you do, you can more easily assess the scope of the work, prioritize and plan the implementation, and write more relevant content.

A medium-sized project is one that might take you a week or two of work, like a new feature that needs one or two new documentation topics, or a few different pages that need to be updated with new content for some to-be-released functionality.

For example, you might be writing medium-sized documentation updates for one of the following features:

An interactive workflow to create and assign tickets to specific users
A new type of widget that can be added to a dashboard
A new SQL function

In this post, I’ll cover how to use data to inform each phase of a medium-sized documentation project like one of those examples:

Planning and writing are often intertwined

For a medium-sized project, planning and writing inform each other. Rather than creating a plan in full, then starting to write, you might go back and forth, acting on some plans as soon as you make them and expanding your plan as you learn new information about the project scope that wasn’t clear when you started. This is common when documenting new functionality — it’s still in development, so the scope often isn’t predetermined and can’t be planned for fully in advance!

Plan medium-sized documentation updates

Planning a medium-sized writing task involves identifying the following:

What is being built?
What do customers expect from it?
What already exists in the documentation?

Use these discovery steps to identify the scope of the project. For example, if your engineering team is adding a new type of dashboard widget that animates images in a repeating pattern, you can use the following data sources to help plan:

Expertise

Business understanding

Research

User research
Product exploration
Documentation exploration
Competitive analysis

System

Documentation metadata

Customer submissions

Feature requests
Customer success call transcripts
GitHub issues or PRs
Search terms
Product reviews
Community forum posts

The planning process relies mostly on qualitative data, so you can inform it with data at most analytics capacity levels. If your organization has a more basic analytics capacity, you can rely more heavily on the data collected through research. If you have a more mature analytics capacity, you can add the more tool and expertise-dependent quantitative analysis.

Plan for maintenance

When you plan to add new pages and content, consider your future self and plan for maintenance too. For example, if you add screenshots of the new dashboard widget, place them in a shared location and record and share the assets used to create them, such as an example dashboard in a shared staging environment. Consider recording the research artifacts that you use to inform your plan in a longer-lived dashboard or collection that is shared with others. This practice of storing your data artifacts can help accelerate the practice of using data to inform future documentation tasks too!

The results of your data collection informs the decisions that you make as part of your documentation plan, namely what types of content to write, how much to write, and where to place the content. Start by considering your expertise.

Rely on your expertise

To determine the release phase, priority, and goals of the project, rely on your expertise.

Expertise

Business understanding

Your business understanding can help you identify why the new functionality is being implemented in the product at all, and what the business is hoping might happen as a result of this new functionality being available. For example, this can guide you in deciding what example to use in a task, or whether a customer might be improving an existing manual workflow with one that is more automated now with the new feature launch.

Your knowledge of the release process and planned priorities can also inform what to write. For example:

In the case of a new dashboard widget that animates images in a repeating pattern, it is an early stage feature that is low priority, so you might only plan a basic task and reference content about how to add the widget to a dashboard and what settings can be configured.
For a new SQL function becoming generally available that unblocks a major customer use case, you might plan a basic reference and multiple detailed end-to-end examples describing the function for the specific use case.
For an interactive workflow to create and assign tickets to specific users, the workflow is the first of many steps to target a new customer base, so while it is an early stage feature it is also crucial for the business strategy. As a result, you plan to deliver a task, a concept, and end-to-end example about the feature. As a lower priority, but planned to align with a marketing launch, you can add tutorials and extra screenshots.

I recommend a similar strategy for building out minimum-viable documentation for a product, and it is still relevant after you have a more full set of documentation to consider.

Beyond considering your understanding of the business and its priorities, you can perform targeted research to inform your documentation plan with data.

Perform research

Inform your plan for the medium-sized documentation updates by performing targeted research to identify what and how much to write. Your main objective is to know as much as you can about the feature — why it’s being built, who it’s for, how it works — to write the best content that you can.

Research

User research
Product exploration
Competitive analysis

User research

To identify customer expectations to help identify what content to write, how much to write, and where to place it, perform user research.

Research

User research

Depending on your analytics capacity , user research might be formal interviews guided by a qualified user researcher, a short conversation with a specific customer that offered feedback about the product, a survey sent to existing customers, or notes taken by design or product leadership as part of the planning and development of the new feature.

Rely on the user research available to you, if any, to inform your documentation plan:

Identify if the target audience of an interactive workflow is likely to be familiar with the relevant tasks involved, or whether it is very new, and therefore they’d want a detailed walkthrough.
Identify preexisting mental models or customer expectations about dashboard widget capabilities that might be informed by the current dashboard widgets, or widgets available from popular competitors that your customers also use.
Identify what key use cases and problems the new feature might resolve for customers.
Define learning outcomes for your content informed by key use cases, such as “Can successfully add a spiral image to the dashboard widget”.

You can use the audience understanding that you build through user research to define details of a task or conceptual introduction to provide for a given feature.

For example, with a new dashboard widget that animates images in a repeating pattern, determine if there are specific customer use cases that led to the development of this widget. Perhaps a hypnosis service company has agreed to purchase your product if this widget is built, so it only has one key use case, but it is a critical one. Additional research and discussions with the product management and design teams reveal that they expect the widget to also be useful to customers nostalgic for Geocities website design and targeting the retro web market.

In addition to user research, you must explore the product itself (if possible).

Product research

Product research is a data gathering exercise , and it’s one that we’re intimately familiar with as technical writers. No matter what your analytics capacity is , you can explore the product and your documentation as a data collection exercise to plan the shape of your project work.

When you perform product research, you can experiment directly with the product, if you have access (and it’s complete enough to do so), you can explore the code directly, or use AI agents as a data gathering tool to either answer specific questions about the product or identify relevant sections of the code to read and review yourself.

Using AI tools for research can risk introducing inaccurate content and assumptions, so if you use AI-based tools for code-answerable questions, prompt the tool to cite specific files (and check its work), include reminders about feature flags or other gates that might affect feature visibility, and verify any claims about the user interface with independent in-product explorations if possible. Consider standardizing guidance in a shared skill.

When you perform product research, especially for a medium-sized project for net-new functionality, collect as much data as you can about the new feature, especially how it works:

What is changing?
What is being built?
How complex is the feature?
What is the entry point?
Is the feature being added to an existing part of the product, or a new location?
How easy is the feature to use?
Are there missing steps or confusing workflows?

The value of a strategic product advocate

Identifying issues like confusing product design or opportunities for alignment with preexisting product features in the planning stage is valuable so that you can give feedback about the design or implementation. As a customer advocate, you can make your strategic value as a technical writer clear.

Use this research to establish the scope of the feature that you plan to document. For a complex feature like a new authentication method for the product or anything that involves an integration with an Amazon product, writing documentation can take more effort. A simple feature, such as the tenth type of dashboard widget that has been added to the product, can be more straightforward to document.

Defining the scope of the project is an iterative and interrogative process. Don’t take the initial scope that you discover as the planned forever scope. As feature development progresses, the scope of the feature can change. What you initially discovered at the start of your research might be an incomplete scope.

These planning and research tasks share some similarities with those that you’d perform for a large project, but they’re different for the feature. In a medium-sized project, where you’re documenting something like a new dashboard widget, there might be more design planning and definition of the future state of the content. The future state planning is present in a large project, and more elaborate due to size, but often more constrained by existing content or project scale. With a medium-sized project, you’re limited mostly by time and priority of the project—namely, what else you’re doing at the same time.

Competitive analysis

For a medium-sized documentation project, it sometimes makes sense to perform a small amount of competitive analysis to gather data to inform your documentation plan.

Research

Competitive analysis

By performing a review of competitor documentation for similar features on the market, you can determine and validate use cases guiding feature development. This kind of review can also help you identify if there are interesting or relevant ways that competitors document the same kind of functionality. Maybe you want to borrow something from their content design, or identify a pattern that you want to avoid.

A competitive review can also help you understand what terminology customers might be familiar with, identifying keywords that you might want to include when writing your content.

Keep a competitive analysis short and contained for a medium-sized project, limiting it to validation and discovery.

It might be tempting to use AI tools for a quick competitive analysis , but I’d caution against relying fully on AI output for this research task. AI tools retrieve content according to what you prompt, thus making organic discovery of content display tactics less likely. It’s a best practice to review the cited sources manually to validate relevance and accuracy, so while you might use AI tools to identify relevant pages in competitor documentation, review the content yourself for relevant patterns and insights.

After performing different kinds of research yourself, you can review other qualitative data sources available to you for some additional planning context.

Examine customer data

If you don’t have much opportunity to perform user research, or if you have a limited understanding of the business, you might want to review different qualitative data sources available to you.

Customer submissions

Feature requests
Customer success call transcripts
GitHub issues or PRs
Search terms
Product reviews
Community forum posts

Customer submissions can be a revealing data source for use cases, terminology, conceptual mental models, and expectations, all of which are valuable for informing your documentation plan.

With data sources like feature requests, product reviews, or call transcripts with internal folks and customers, you can gather information about how customers talk about the new interactive workflow being developed, or the exciting new dashboard widget.

For example, based on customer feature requests in support cases and GitHub issues, as well as customer success call transcripts, you recognize that customers are concerned about the performance of dashboard widgets, which is unclear for most widgets. As a result, you can add an item to your documentation plan to test and provide details about the performance of the new dashboard widget that animates a repeating image.

You might not be able to prioritize that type of content for an early-stage, low priority feature, but by using data to inform your plan, you’re going beyond the basics of “document the feature” and instead being more strategic, planning to deliver more practical and relevant content to users.

A risk with these data analysis phases, compiling business understanding and user research with customer-submitted data, is that you weight internal assumptions and plans for product positioning more heavily than your findings from user research and customer data. Just because your organization wants something to be true and wants your customers to understand something about the new feature based on the planned marketing and product positioning, doesn’t mean that they will. You need to understand the customer’s mental model and preexisting expectations to write effective content — and that can require more effortful research and data analysis.

Use data to define what to write and where to place it

After you use your expertise, research, and review of customer-submitted data to define the scope and identify customer expectations, use that information to plan what to write, how much to write, and where to place it.

For example, identify the type of content to write based on the feature:

An interactive workflow to create and assign tickets to specific users might require you to write a task, a use case, and requirements.
The new dashboard widget might require you to write a task for how to add the widget, a reference for the available widget settings, and an example use case for the widget.
A new SQL function might require you to write a reference topic about the arguments and output, as well as several examples of the function in use.

For the content to be findable, you must identify where people (and AI agents) might look for information about the functionality. For example:

Content about an interactive workflow to create and assign tickets to specific users might be placed by existing triage and assign workflows, or organized with other content targeting the same audience.
Content about a new type of widget that can be added to a dashboard might be placed by other widget docs and added to a parent reference list of available widgets.
A new SQL function might be placed with similar types of functions, or even organized with the name of a competitor’s SQL function as an alias in the navigation to improve findability.

To take a data-informed approach, you can use the following data sources to plan how to structure the content and where to place the content:

Expertise

Business understanding

Research

Product exploration
Documentation exploration
Competitive analysis

Customer submissions

Search terms
AI chatbot conversations
Feature requests
Community forum

System

Documentation metadata

Most of these data sources are qualitative. Because you’re writing something new, you want to identify existing patterns and mental models that might exist in the industry, but otherwise you’re largely relying on your expertise and understanding of the customer and business, plus research about the existing documentation content and new product feature when deciding where to place the new content.

You don’t need to use all of these sources to help inform your key content decisions. Use the approach that makes sense, given what you can do easily, quickly, or effectively based on your available tooling and analytics capacity.

For example, to guide the following key content decisions as you define your plan of what to write, you can use the following data sources and analysis questions:

Key content decisions	Questions to ask of the data	Data source
What should I name the topics? What keywords should I mention in the opening of the topics?	What terms do customers use today when looking for information about this? Are there unsuccessful searches for this concept already?	Search terms
How should I frame the topic? What keywords should I mention throughout the topic? What terms should I make sure to use consistently? What use cases should I use for examples? What mental models should I make more explicit?	What questions do people ask of an AI chatbot? What terms do they use when looking for information about the subject that you’re documenting? Are there questions with made up responses in the AI chatbot conversation data?	AI chatbot conversations
What use cases should I use for examples?	Have customers asked for this functionality? What reasoning do they provide?	Feature requests
What other features should I mention to disambiguate the jobs-to-be-done for the feature?	What use cases are customers trying to accomplish already that this feature could address?	Community forum
What information should I include in the introduction? What use cases should I use for examples?	Why is this feature being built? Why now? What gap in the market does this feature fill?	Business understanding
How should I structure my content? What terms should I use in my content to improve findability	What content do competitors have about similar functionality? What information do they provide?	Competitive analysis

Your documentation explorations can help you understand how and whether similar, but different, functionality is documented for your customers. That research can guide how much content design work you need to do in deciding how to document the new dashboard widget, as well as identifying what patterns your customers might expect from your dashboard documentation content.

To help identify where to place the new page in the navigation and information architecture, answer the following questions:

How is the company positioning the new feature or functionality? Is there similar or existing functionality that is positioned in the same category?
What sections exist in your information architecture today? What architectures are possible with your tooling?
Where do competitors place documentation about similar functionality, if it exists?

To help you assess page structure, answer the following questions:

Where do people searching for information about this functionality end up today? What terms do they use?
How long are the existing pages about a feature? Consider using page length as one indicator to help you decide whether to write a new page or update existing ones, in addition to content type.

At this point in your medium-sized documentation project, you have a detailed plan outlining customer expectations, project scope, and a sense for what content to write, how to structure it, and where to place it.

Your next step is to write the content.

Write a medium-sized documentation project

The writing process is where you focus on delivering on your data-informed plan — both writing the content itself and placing it in the designed structure. Planning and writing are intertwined, so as you continue using the product to draft your task, you continue reevaluating the scope and updating your plan for what to write and how.

For example, start drafting a task outlining how to add the widget to a dashboard, featuring an example that combines with widget with another widget type, as well as a reference topic outlining the formatting options available for the widget. As you build an example dashboard to support your content about the new widget type, you might discover a missing setting that won’t be added in time for the release, so you write a note about it, updating your plan and your content in tandem.

Before AI-enabled writing workflows were common, writing was the stage where using data to inform your process was the least relevant, but that’s no longer true. If you draft content with AI agents in the loop, you can use the data from your planning stage as part of the context that you provide when creating a draft. For example, provide the specific use cases that the widget was designed to support, the terms used by customers and internal folks when describing the functionality, as well as references to existing similar pages to align structure and style of the content with existing dashboard widget task and reference pages.

If you don’t use AI in your writing workflow, you can still use the data sources and metrics that you reviewed during the planning process to inform your writing process, especially to validate assumptions about the right approach to take during the writing process:

As you write examples, consider the customer use cases to assess the relevance of the examples.
As you write headers, titles, and introductions for pages, review the customer search terms and keywords used internally to describe the feature to evaluate the discoverability of the content and the consistency of your language.
As you structure the content, evaluate if you’re matching the format of existing similar content types, or intentionally deviating.

Decide whether to add screenshots

When you plan new content, you can use data to help you decide: Should you add screenshots to documentation?

Screenshots are most helpful when they are relevant to the readers and useful for the context of the documentation. How do you evaluate that? With data!

For example, when adding documentation about a new dashboard widget that animates images in a repeating pattern:

Use on audience research:

Is this widget concept totally new to them?
Do they know how dashboard widgets generally work?
Are they familiar with a different configuration UI for widgets?

Use product and documentation research:

Is the widget setup design confusing?
Are you providing a reference, task, or example topic?
What is the goal and learning objectives of the topic?
Do similar topics have screenshots?

Use your business understanding:

What resources exist to help you maintain the screenshots?
Can you automate the screenshots with the tools available to you?

In this case, you might recognize that a new dashboard widget that animates images in a repeating pattern is a new concept for many readers, so adding a screenshot of how the widget looks when fully configured to the task documentation to illustrate an example can help support the business value of the feature.

If you have a higher analytics capacity, you can use additional data sources to validate the decision to add one screenshot.

Review page quality feedback for dashboard widgets:

Are people requesting more screenshots?
Do topics with screenshots get more or less page quality feedback?

Review website analytics for dashboard widget pages:

Compare the page views and referrer traffic for a high quality dashboard widget topic with screenshots to one without screenshots.
Compare the click activity on the similar pages, do users click or hover over the screenshots on the page with screenshots?

With a data-informed understanding of the product, your audience, your business capabilities, and current user activity, you can make a sustainable decision about screenshots.

You’ll likely redo some product research as part of the writing and revision process, because the product has likely changed since you started planning and writing. For example, check the product to validate the accuracy of your documentation draft, ensuring that you reference accurate UI strings and navigation paths, as well as relevant option and parameter names for API workflows.

After you write, revise, and publish your medium-sized documentation project, it’s time to evaluate it.

Evaluate medium-sized documentation changes

Were the docs useful to your customers? Are they accessing the docs? Are they asking questions answered in them and are the docs helping to answer? These are key questions to consider when evaluating medium-sized documentation changes.

When you add content about a new feature, there isn’t a baseline to compare against, but you can still evaluate what you produced.

First identify if you hit the most basic goal of delivering self-service support that is clear, useful, and relevant to your users.

One good signal can be the volume of internal questions. Oftentimes, the first readers of documentation about a new feature are the sales and support folks that are trying to understand it on behalf of customers that they’re helping, or prospects that they’re pitching. If you don’t see that many questions, or if the vast majority of questions can be easily answered with a link to the documentation, that’s a good initial signal that your documentation is useful and relevant.

However, the internal customers are not your primary audience, so you also want to evaluate more customer-specific metrics.

Short-term evaluation

In the short term after the release, monitor support cases and chat volume, product bugs and GitHub issue reports, and search queries to identify missed opportunities in the content or validate successes. Medium-sized documentation changes, or any changes to support a new feature, are perhaps the only changes for which you can do some preliminary evaluation immediately after a release.

What you can evaluate, how effectively, easily, and coherently, depends on your analytics capacity. The higher your capacity, the easier it is to evaluate quantitative metrics like feature adoption, documentation page views, and support case volume together on a graph and evaluate correlations against baseline usage. If you have a lower analytics capacity, you might not have a quantitative baseline, or one that you can make much sense of to help you evaluate this medium-sized change. In that case, you can use a more qualitative approach to evaluating your success in the short term.

Correlate quantitative metrics

After a release, you’re likely to see different post-release correlations across those three quantitative metrics:

Product telemetry
Support case volume
Website analytics

For example, for a new dashboard widget that animates images in a repeating pattern, if a lot of customers were waiting for it and closely followed the release notes, you might see both feature usage and documentation page views for the new pages increase after the release, such as in charts A, B, or C.

If the release was not hotly anticipated or perhaps is for a feature that was already broadly available and just reaching general availability, you might see a pattern like chart D in a short term evaluation. Compared to the product usage metrics generally, feature usage didn’t increase — not much has changed compared to before the release.

For a feature with immediate adoption, you can evaluate the short term success of your documentation by assessing the trend of the documentation usage and support case volume for pages and cases related to the new feature.

For chart A, assuming a feature going from private preview to public preview, people are using both the newly public feature and its documentation, but still confused enough to contact support with roughly the same relative frequency as when the feature was available only to select customers privately.

For chart B, people are using the feature and its documentation, but a brief dropoff in feature usage could indicate a lack of success with the feature. The continued documentation and support usage likely indicate confusion with the feature that probably isn’t fully resolved by the documentation. If the dropoff was due to a seasonal holiday, you’d expect to see usage of all three metrics go down at the same time, which is why it’s important to review the metrics together.

For chart C, the usage is a bit noisier in the data, but it’s generally a good signal for product usage and documentation usage to go up while support cases either stay flat or go down, indicating that folks are using the product generally successfully with help from the documentation as needed, without needing to contact support for much help. You can also perform a spot review of support cases before the feature was widely available and after, to determine whether the higher volume was customers asking about the availability of the feature or asking for help with it.

I recommend looking at all three metrics together. If you look only at documentation page views (as a way to proxy usage of the documentation pages that you added) you might draw misguided conclusions about the documentation usage.

For example, if your new dashboard widget documentation has very few page views, you might think it’s not useful. But if feature usage for the new widget is also very low, that indicates that the low documentation usage is likely unrelated to your content.

Instead, something else could be happening. If the feature wasn’t announced, or doesn’t address a gap in the product felt by a large segment of the product audience, product adoption might be slow. Discoverability of the feature itself influences interactions with your documentation, especially in the short term.

If the only data you have access to is documentation page view data, you can reliably use it to evaluate awareness of the feature, but not usage or success.

Even if you don’t have only sparse and statistically insignificant quantitative data, it can still be useful for decision-making and informing your documentation practice. Bob Watson elaborates in his post: If it’s not statistically significant, is it useful?.

Consider qualitative sources

Beyond correlating three quantitative metrics together, you can assess more qualitative data sources to attempt to extract more intent-rich insights. For example:

Customer submissions

Support cases
Product bugs
GitHub issues and PRs
AI chatbot conversations
Search terms

You don’t need to review every data source in this list, and you don’t need to review all content from each source. Reviewing a sample of just one qualitative source, especially if you have a basic or growing analytics capacity, can give you some useful information.

Data source	What to look for in the short term
Support cases	Do you get cases confused about the new feature, or with questions not addressed by the documentation? Is there a pattern to the questions? Are the questions about the feature more complex than before, indicating that perhaps more basic questions have been addressed by your documentation?
GitHub issues and pull requests	Do people open issues asking about functionality supported by the feature? Are there problems with its functionality for some customer deployments?
AI chatbot conversations	Are relevant questions being answered more accurately? How are the evaluation scores for the new content?
Product bugs	Are there any bugs with the feature discovered by customers or QA after the feature launched? Do any of them necessitate documentation updates? (Like a limitation that was missing from the docs)
Search terms	Do search terms about the issue find results? Are there fewer unsuccessful searches? Do you have a higher % of clicks on the page that you updated? Is search volume higher?

GitHub issues, and especially pull requests from contributors, can be an indication of product usage even if you don’t collect or have access to product telemetry. However, there is a risk of relying on those as a signal without correlation from other channels of data. People file issues and contribute pull requests for functionality that they’re using and want to improve — but a lack of issues doesn’t mean a lack of usage for a product feature — it might be frequently used but satisfactory in its current state.

Another assumption to avoid when analyzing product telemetry data (either directly or implicitly through product bugs and GitHub issues) is assuming that current and past usage patterns are indicative of future usage patterns by a customer. A customer testing and planning to roll out the new functionality to their user base looks different in the usage patterns than a fully scaled production workflow.

To mitigate these risks, correlate any decisions or conclusions drawn from product telemetry alone with user research, either by talking directly to customers using the capability, or at least the internal stakeholders that work directly with those customers, such as Customer Success Managers or Professional Services teams.

In some cases, you might want to perform a longer-term evaluation of the content you added for your medium-sized project.

Longer-term evaluation

If your product customer base is largely enterprise-sized organizations with slower adoption curves, or you’re attempting to assess documentation that supported a relatively low-key unannounced feature, a longer-term evaluation is more useful than a short-term data check.

In these cases, you can use the time immediately after the release as a pseudo-baseline, and correlate product telemetry for the feature with documentation usage to evaluate any patterns .

Data source	What to look for in the longer term
Website analytics	The page views and click interactions with the page, such as clicks on code samples or clicks to highlight text, increase. User sessions and referrer traffic indicate that the journeys to get to relevant information (the pages you created or updated) are shorter.
Product telemetry	Evaluate documentation usage with product adoption data to determine if there is a correlation.

For example, for readers using search or other pages to access information in your documentation, their paths might go from messy and convoluted session activity patterns:

To a more streamlined and simple approach where they land directly on a relevant page:

Interpreting session length depends on topic type

A shorter session length makes sense only in context of the documentation content.

A short web browsing session on the documentation site could mean any of the following:

Someone got frustrated and left without finding the answer they sought.
Someone found what they needed quickly and left to return to their task.
Someone was mid-exploration and they got interrupted by a surprise software update restarting their computer.

When attempting to interpret user session activity, compare a specific session against a baseline session length for similar topic types and audiences.

Someone with a long documentation session, visiting conceptual pages, reference pages, and task pages in the same session might be frustrated trying to find a specific piece of information, or they might be learning and trying to understand the feature before they start using it.

For example, if the topics are all about configuring authentication and provisioning new users, the session might be more likely to represent a thorough reader when compared to a similar session journey through dashboard documentation — but it might not be! Quantitative data cannot encode intent, only activity and volume.

Evaluate different pages differently

If, due to your analytics capacity , you rely primarily on page view analytics to evaluate your medium-sized documentation changes, you must evaluate different page types differently. You cannot derive one single metric to define the success of every documentation page that you publish. Instead, you can evaluate specific pages.

If you don’t know what the goal of a specific page is, you cannot evaluate its success.

Page	Goal	Measurement
Documentation homepage	Attract customers from search results Direct customers to other pages	Track sessions started from organic traffic Track on-page click volume and targets
Task (How to do X, Create and manage Y)	Help customers accomplish a task Provide instructions	Track support case volume Track search term volume landing on this page
Landing page	Provide a conceptual overview of content Direct customers to other relevant pages	Track page views with this page as a referrer Track page rank in search results for generic search terms about the topic
API or code reference	Help customers write code	Track clicks to copy code examples Track successful endpoint requests performed on the documentation page.

There are some universal data signals for documentation pages, but they require additional time-consuming analysis to be reliable, such as:

Tracking MCP server interactions that return the page, which requires validating the accuracy of the response to validate usefulness.
Tracking AI chatbot conversations that reference the page as a source, which also requires validating the accuracy of the response to validate usefulness.
Tracking page quality feedback on the page, which is a low-volume self-selecting signal that isn’t representative of all users.

The goal of evaluating your changes over the short term and long term is to evaluate the success of your content decisions. Keep track of what worked for a specific project, note what you might want to repeat, and share it with your colleagues.

Use data to inform a medium-sized documentation project

When you use data to inform a medium-sized documentation project, you can more effectively plan the scope of the work and design the content required. As you write and review the content, you can make decisions, iterate on the plan, and add context to AI-powered tools. When you attempt to evaluate the success of your project, the data you gather and analyze can validate the usefulness of your approach.

new feature documentation on This is important

Inform a medium-sized documentation project with data

Plan medium-sized documentation updates

Rely on your expertise

Perform research

User research

Product research

Competitive analysis

Examine customer data

Use data to define what to write and where to place it

Write a medium-sized documentation project

Evaluate medium-sized documentation changes

Short-term evaluation

Correlate quantitative metrics

Consider qualitative sources

Longer-term evaluation

Evaluate different pages differently

Use data to inform a medium-sized documentation project