By Jenifer Schlotfeldt
High-quality documentation exudes the authority to meet any customer’s expectations
In many companies, documentation is an afterthought to delivering a product release. Writing teams often feel underappreciated and are typically viewed as a cost center. It’s not because documentation isn’t an important part of the customer’s pre- and post-sales journey. It’s because, as writing teams, we’ve had difficulty showing documentation’s revenue-generating impact.
Here’s what I’ve learned about how to represent documentation’s contribution to my business’s bottom line, and ultimately, getting non-writers in my company to care more about docs.
Quality Documentation
First, we ensure that we are delivering good, high-quality documentation and can show that our documentation meets customer expectations.
Using tools to automate quality checking can help to make the writing team more efficient, especially in a continuous-delivery environment. Automated tooling can check for things like:
- Spelling: Are there any typos?
- Grammar: Is the content grammatically correct?
- Style: Is it following the company style guidelines?
- Accessibility: Is it passing all the accessibility requirements?
- Broken links: Are there any broken links to other pages within, or outside, of your documentation?
We also have editors to provide what the quality checkers can’t. They give input and guidance on the kind of content we’re providing, as well as consistency, organization, and information architecture.
Last, subject matter experts and technical owners check the technical accuracy. We work with them to ensure we’re producing documentation that covers the product as it is intended to be used — not just covering the features and how they work.
All of this adds up to the final deliverable and customers letting us know if it meets their expectations. That typically comes in the form of user comments or ratings from tools like feedback surveys.
In our experience, documentation is not a top driver of our Net Promoter Scores® (NPS), but documentation consistently comes up in comments. Good quality documentation earns your customers’ trust and sets them up to help themselves at any stage of the journey with your product. This can ultimately be a positive driver for a good NPS.
Analyzing Data
Next, we look at user behavior, user data, and detailed user feedback.
User testing documentation — or partnering with the folks leading product user testing — is a good way to understand if the content and format are correct and whether the right functionality is available in the publishing site. While running users through tests, we leverage the opportunity to get input on any content we produce — for example, to understand if user interface text or terminology is working, needs updating, or needs to be added. The best test to run is asking the tester to complete a task
by using the documentation.
User research helps to really understand who our users are: novice, technical, and so on. Research can also help discover how users will really be using the product. This research also helps to understand what features, format, or content will delight users the most.
The data collected on user behavior helps to understand:
- How they use the documentation delivery application
- How they use the embedded help system
- How they use the content in combination with the product
- What they access, in what language, and on what kind of device
When looking at what the industry is doing, ask:
- What term is the industry using?
- How is similar content being delivered?
- What’s a standard?
- What features in the documentation delivery application could be helpful to my users?
Sometimes you can take action on user comments, and you know exactly what to fix — typos, missing content, or incorrect steps.
At other times, the comments aren’t actionable, but data can help to identify the real issue. Ask:
- Do we see a lot of issues with the content quality?
- Do we see other comments that provide more actionable feedback?
- What does the user testing say?
All this data provides insights that can be shared with other areas of the business. It shows the impact that documentation has in the customer journey, whether that is how and when they are using the documentation, or how important the documentation is to them.
That’s not the data, however, that really shows documentation’s impact on revenue. You might also think that page views are the only metrics you can gather about your documentation. But we have lots of metrics available to us, including being able to see how our content impacts account creation and rated usage.
Showing that documentation is part of the marketing and sales funnel that ends with account creation, money spent, or some other conversion metric makes clear the importance of documentation to your customers.
Non-Writer Participation
Spend time with other areas of the business to get additional insights about how well the documentation meets customer needs. Most customer-facing team members hear first-hand when a user is unhappy with the product, especially if they can’t find any documentation to understand a feature. Not only does this input provide more insight into the quality, accuracy, and use of your documentation, but it also creates connections with others who can contribute and participate in creating the right documentation for users.
Building these relationships begins to pave the way for a corporate culture shift around the importance of documentation. It provides an opportunity to show that there is an easy path to collaboration and to get the right documentation published. It also provides more data.
At the end of the day, money talks. Understanding what data you have access to and how to connect documentation to purchases can be the best ways to prove how much documentation impacts revenue.
JENIFER SCHLOTFELDT (jschlot@us.ibm.com) is a senior content strategist and the content experience architect for IBM Cloud. Jenifer leads a team of software engineers and content designers who own the IBM Cloud Content Experience. Not only is the team supporting the continuous delivery of the IBM Cloud Docs and API Docs, but they also embrace DevOps and Design Thinking practices. She is also the coauthor of DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA.
