It’s alluring to use data to drive every sort of decision and action. When you write content for the web, you can gather all kinds of data about your website traffic. Why not put those metrics to work for you?

The content marketing industry is experienced at using data to guide content development, but documentation isn’t marketing. While documentation can drive qualified leads and be helpful to prospective and existing customers, the ultimate goal is to support users in solving their problems, guiding them through using the product, and validating expectations about how the product should work.

As a result, measuring the success of documentation looks less like calculating the number of qualified leads generated and form fills received based on a specific campaign, and looks more like attempting to quantify usefulness, helpfulness, and quality.

Those metrics can be too muddy to measure, but that doesn’t mean that data can’t be involved in the documentation process. Instead, data can play a critical role in planning, writing, and evaluating your technical documentation. I like to call it “data-informed documentation”.

What is data-informed documentation? #

Data-informed documentation is the practice of using data to supplement and guide key steps in the documentation process, namely:

• Planning and prioritizing what content to write
• Writing, reviewing, and revising content
• Evaluating the usefulness and quality of content

Data-informed, not data-driven #

I’m intentionally framing this practice as data-informed rather than data-driven. Instead of the data driving our actions, it can inform them. Data is context, not expertise. As technical writers, we have valuable expertise in the product, documentation set, and the audience(s) for whom we are writing.

Use data as an enhancement, not a replacement. If you use AI tools as part of your writing process, specific data sources can quite literally inform the context of your work.

No matter how you craft your content, use your expertise to define the path and the data to help light the way.

Why do data-informed documentation? #

There are always competing priorities for a technical writer.

• Product development steamrolls ahead, delivering new functionality that needs to be documented.
• Customers are contacting support about functionality that launched 2 years ago and hasn’t been updated since, but still gets a lot of use.
• Sales is selling effectively, but customer retention isn’t as high as leadership would like.
• Engineers keep shipping updates to the API spec without telling you.

The tasks pile up: new feature documentation, important updates to existing content, tutorials to onboard new users, automated review workflows to improve the quality of engineering-driven content.

It’s easy to be overwhelmed by competing priorities or afflicted by the curse of knowledge. When you’re confronting the uncertainty that pervades the documentation practice, data can help reduce that uncertainty to something more manageable.

How to do data-informed documentation #

Given how fast-paced a technical documentation practice can be, what does data-informed documentation look like in practice?

Start by assessing the resources available to you and evaluate your data-informed readiness: Prepare to deliver data-informed documentation.

Then, pick a project to work through:

Make data-informed documentation a practice #

As you establish your analytics capacity and start exploring data-informed documentation, consider how to make data-informed documentation a repeatable practice. Build the habits and implement the processes that make practicing data-informed documentation easy:

• Set up metrics and reporting in an accessible tool.
• Use data to inform your work when it’s relevant, useful, and available.
• Automate the reports to appear in Slack or your email.
• Make your analytics queryable by an AI agent.

The structure of the data, the tooling available to you, and how you can add it to your workflows is what makes a data-informed practice sustainable instead of aspirational.

As Sarah Deaton puts it in her post, Docs metrics and the stories we tell ourselves:

the real work isn’t finding the one metric that says it all; it’s staying curious, asking better questions, and building a system that gets a little less wrong each day.

Data-informed documentation offers a framework for building that system.