[with] over seven billion permutations.”
In reading their introduction, I was struck by the relationship of the authors’ discussion with the problem faced by information-development management. We all know of instances where technical content has proliferated far beyond the ability of anyone to use it. We hear of manuals that run to thousands of pages and products that are “supported” by tens of different manuals. Managers intent on implementing content management and topic-based authoring feel oppressed by the sheer volume of legacy content. They wonder if it is possible to “convert” it all to DITA or another standard.
How do we face the problem of cutting complexity in our information-development world?
The suggestions that Gottfredson and Schwedel offer are well-aligned with the Minimalism Agenda that we and other proponents have developed over the past 25 years. The beginning point is called “zero-basing.” I’m sure you’re familiar with a politician’s favorite called zero-based budgets. That means that for each budget cycle, you begin with the assumption that nothing is funded. You must justify every product offering or content stream based on its cost and its value to the customer and the company.
Zero-basing becomes an important thought process. We must ask our team members to begin with no documentation:
- If we could only produce one information collection for our customers, what would it be?
- In producing that one information collection, how much would it cost?
- Is the cost commensurate with the value of the information collection to the customer?
- If we choose to add two, three, or many more information collections, will they meet real customer needs rather than our own preferences or those of internal advocates?
In asking the right questions and seeking responses from real customers, we can often come to the conclusion that much of the information we continue to maintain has low value and high cost. Once we make decisions to minimize the content collections, we have to be vigilant about increasing the complexity as we respond to customer needs or the needs of those pesky internal advocates for “more, more, more.”
Gottfredson and Schwedel provide three steps to ensure that we never again are drowned in the complexity of our product offerings. Each of the steps can easily be applied to technical content and product information in general:
- Calculate what complexity costs
- Find out what customers truly value
- Remain vigilant
Let’s examine each of these from the point of view of technical content and minimalism.
What Does Complexity Cost?
The authors start with the basics. Think about the one critical manual or help system that you would produce to support your product. Then calculate exactly how much it would cost you to produce that single deliverable (or single-sourced set of deliverables). That cost is your base line, representing the minimum cost of producing information that has value.
For example, you might decide that you need to produce a user guide that helps customers reach goals and perform actions that are not ordinary. You make this choice because you recognize that the basics are taught in training and are relatively easy to learn. Once people learn them, they never look them up. You’ve learned that they use documentation only for infrequently performed tasks or more complicated operations.
You might calculate that you require one person working half of the year to update this user guide, a sum of approximately $60,000 in personnel costs. Add to that basis all the other development costs associated.
Then, begin to add the costs of all the other information you develop for the same product. The authors point out that most organizations observe that their costs don’t rise gradually from one additional product to another. They jump at some point where the more you are producing, the more the production strains your ability to produce. When you move, for example, from a few manuals per writer to 10, 20, or more, the writer spends more time remembering what to do on the next project than actually doing any work.
It seems quite obvious at this stage that you put the right processes in place, especially those like duplication of content among deliverables, that drive your costs up. Most of you working with topic-based authoring, DITA, and content management have recognized how to simplify your information-development processes. At the same time, you need to look hard at what content you can completely eliminate. Minimalism suggests that if the content is not needed by the customer, it should be eliminated. We especially target the filler content usually found in Prefaces and Introductions.
We have learned of so many case studies in which content volume was reduced by 25, 30, even 50 percent simply by eliminating content that had no value to the customer and pruning “nice to know” content away from the “need to know.” Such reductions in complexity and improvements in usability are the reason we recommend Minimalism as the first step in preparing for content management.
What Do Customers Truly Value?
I usually ask participants in the Minimalism workshop about their customers, and their response is often “we don’t know the customers.” The most predictable results of not knowing what information customers truly need and value is an increase in the complexity of the information offered. Writers often end up explaining what users already know and failing to explain what they don’t know. I recall a writer who decided to spend two to three pages explaining how to turn on a 1/0 switch on a plotter. Only after the editor spotted the problem did we understand that the writer’s conceptualization of the user was far off the mark. We couldn’t conceive of a technician onboard a Navy ship not knowing how a 1/0 on/off switch worked.
We often hear that customers are dissatisfied with documentation and want “more content.” That’s a very common conclusion from the interactions that sales or service might have with customers. When a team at IBM researched the “more content” problem with their audience of software developers, they discovered that the customers really wanted more relevant code samples with more annotation. On their own, the customers did not know how to explain what “more” meant.
The same problem exists with product management and marketing. They respond to customers who are asking for more choices by adding features to the product. The authors of the article recount the story of a supermarket chain that luckily did not respond at face value when customers appeared to ask for more choices. They found that customers did not want a greater number of items but wanted to find the items more easily. Sounds like my local supermarket—I never can figure out where they’ve hidden something I’d like to buy.
Information developers must be careful about responding to perceived customer requirements by adding more content and increasing the complexity of the information. Better to ask exactly what will do the job.
There really is no excuse today for not connecting with the customer. Companies that automatically turn down requests by information development to meet with customers are doomed to excessive complexity and excessive information-development costs.
How Do We Remain Vigilant?
Even if you’ve learned something about your customers in the past, remember that customers change. As our companies react badly by adding more and more functionality, information developers seem to feel that they have to follow suit and add more complexity to the documentation.
The solution that Gottfredson and Schwedel suggest has three parts (to quote):
- Keep the business model simple.
- Raise the hurdle … any new product or service must clear.
- Prune the garden.
From the point of view of information development, these safeguards to adding complexity back into an information suite begin with the assumption that less information is better information. Fewer words, fewer topics, fewer manuals—all of these contribute to keeping the service simpler and less costly. Be certain that whenever you consider adding more to the information, increasing the size of the manuals, go back to the original plan. Carefully evaluate the costs and benefits of each addition. Even you have to add something (topics, pages, explanations), take something equal away. What content might you select that offsets the cost of the new content?
Our primary responsibility to our larger organizations is not to document everything that comes along. As the authors note, “runaway complexity” does not enhance the customers’ experience with the information products we produce. Adding complexity reduces our productivity and calls our entire enterprise into question.
Reduce complexity or find that someone else will decide that your enterprise has become too costly to support. Move to simplicity and minimalism and ensure that you are adding information that customers value while removing outdated and any useless content that lingers. In doing so, you have the change to deliver better value to your most valuable customers.
Gottfredson, Mark and Andrew Schwedel. 2008. Cut Complexity—and Costs. Harvard Management Update. Volume 13. No. 8.