Documentation Metrics

[article]
What Do You Really Want to Measure?

customers and use that feedback to create a polished information product that will effectively transfer knowledge to customers. A clearly defined rating scale in a documentation feedback survey of this sort has more value to the organization than measures such as "number of pages/day" that are irrelevant to the customer.

Customer Support Improvements
Team up with customer support to design a response form (or add fields to existing forms) to determine how many calls are related to documentation, and give that information to the documentation team so it can quickly update online publications. Track this information over time to show the decrease in the number of documentation-related calls so you can assign a dollar figure (a quantitative measure) to any metric. Incorporate nondocumentation customer issues and resolutions into subsequent information products. Broadcast your results throughout management just as you did for the Web-based feedback.

Fallout from Bad Metrics
Dangerous Misperceptions
Mechanical metrics contribute to the idea that "anyone can write documentation." And they can, if all that matters is conforming to some arbitrary metric that has no relationship to quality.

 Downsizing Ammunition
Managers often seek mechanical metrics to simplify their accounting. However, when it comes time to trim "overhead services" (as documentation and publication groups are often called), these mechanical metrics make technical communicators easy targets for the budget axe. This can and does happen in many organizations, as I've experienced.

The Bottom Line
We can produce user documentation that is accurate, complete, organized, and clear and that contains sufficient entry points (table of contents, index) and visuals, but still does not meet the needs of the target audience. This leaves us with two firm conclusions:

  1. It is the feedback (and input) from the target audience that should matter the most when it comes to implementing any documentation metrics
  2. Documentation metrics must be tied to the bottom line and broadcast to management if they are to have any meaning outside the documentation department.

I have never heard a customer complain about a misspelled word or a few misplaced modifiers. However, I have had customers pitch fits about ambiguous, incomplete, or incorrect content. Our documentation metrics should reflect the realities we experience in our exchanges with the customer.

Imagine having a technical publications operation that works in close cooperation with customer support to track and correct the deficiencies reported by customers and internal users. Our information products would ultimately make customer support unnecessary because of the quality of the product and information design...What halcyon days those would be.

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01