Relying on the Wisdom of the Crowds with Help Authoring [Organizing Content #20]

by Tom Johnson on Jul 27, 2010
categories: findability • technical-writing

The most compelling idea from emergence, which I explained in my previous post, is the surprising wisdom of the crowd. The guesses of 800 people about the weight of an ox at the county fair averaged out to be just one pound from the actual ox's weight.

The wisdom-of-the-crowds idea is revolutionary. Traditionally "the masses" are unintelligent compared to the elitist class or the lone genius. But now we have a reverse assertion about the formation of intelligent systems.

Now let's bring this argument to the context of technical writing. You're creating a help system, but not just any collection of help topics. You're trying to create an extremely "intelligent" help system, so you extract the most relevant information for your users. You study their tasks and behavior, their pain points and business needs. You write hundreds of help topics describing different concepts and tasks in the application. You organize all the content into logical folder structures, and you even use the same terminology as your users.

You're not just trying to document every task and screen in the application. You're trying to create a system of knowledge that answers, in as succinct and findable way as possible, every user's immediate question. You're trying to create help that, almost with the snap of a fingers, gives the user the exact answer he or she needs -- without frustration, without exasperation, and without requiring any calls to the support desk.

Given the diversity of users, their skillsets, and the problems they encounter, creating this type of help system requires an exceptional skill and genius. It isn't merely a task like writing an email or composing an essay. A good help system is a complex system that exhibits a high degree of intelligence.

What About the Lone Genius Model?

I don't deny the validity of lone genius model. Often it takes a lone individual to see past crowd-think and to formulate an original idea. But when it comes to help authoring, I'm not sure the lone genius model works so well. However much you reason out the help topics and their organization, you're hopelessly trapped by your own perspective. All too often, you include the amount of detail you would need if you were the user. You organize the topics into containers that make sense to you. You use operate from your point of view.

While your point of view may be informed and mostly on target, you won't have the benefit of organizing your content to meet the needs of the entire crowd without the input of the crowd.

Rather than write and publish your help content alone, consider another model. Your efforts to write and publish help content just get the momentum started. After you publish your help content, it passes through the hands of dozens, even hundreds, of people. Let's assume all those people read the content and add or edit the content according to their perspective and business needs. Suppose, like Wikipedia, that you have hundreds of users analyzing and shaping the material. They see the problem from a thousand different perspectives. Any gaps, unanswered questions, unexplored bugs and quirks or other need-to-know nuggets of information they add. Now instead of the product of one mind, you have the collective intelligence of the crowd. The information is much more complete and answers every possible question users could have.

Relationships Between Content and Organization

This model sounds persuasive, but it may be more of an exercise in theory than practice. While the product of a thousand persons' edits may produce complete and thorough information, it also produces chaos in terms of organization. This is evident in any robust wiki. Wikis with a lot of content are almost always mazes of confusion. The WordPress Codex is the ultimate example of this chaotic organization.

It seems that you could describe a type of relationship forming here. The more people who contribute to help material, the larger and more complete the help material becomes. However, the more information you add to a system, the more difficult it gets to organize it. If the organization is weak, it becomes more difficult to find the information. Hence the abundance of information added by the crowd becomes less usable because it is less findable.

.

Despite this loss of tight organization, a good search engine (especially one with advanced search options) can be a quick way for users to find information even in a maze of chaos. I don't mind if the organization of information on the WordPress Codex is impenetrable, as long as I can locate a list of relevant results from the search.

It seems that, in the end, you have to trade tightness of organization for completeness of content.

Mission Impossible?

I'm only skimming the issues here. No doubt most tech writers reading this will ask how they could ever possibly leverage an entire crowd to both read and contribute to the help material. Most tech writers never even interact with users at all, let alone have the potential to leverage the input of a crowd of users.

Even if you did have a thousand users at your disposal, what exactly would you have them do? Read through your help with a red pen? No. Give them a big edit button on each wiki page? Maybe. But users leave their marks in more ways than one. The tech writer can gather some of the crowd's input by analyzing web metrics. If you're tracking your help, a mass of hits on one topic indicates interest in that topic, so you can expand on it. If you can capture keyword searches, even better.

When you exhaust metrics on your own help system, turn to the granddaddy metric: the support center. What kinds of calls are they getting? Track the incidents logged, and use the resolutions to the incidents to increase the completeness of your help.

You can also gather feedback from the product manager, any trainers, and any other people who interact with your users.

Stumbling Blocks

While this method of gathering information from users to make the help more complete may sound like a good strategy, I doubt it will ever be implemented, for several reasons:

• Most tech writers stop working on documentation post-release. Once software is released, the budget for their project ends, and tech writers have to move on to another project. The model I've been describing suggests a continuous attention to the product and related issues post-release.
• Most tech writers don't really care. Expectations for the quality of help content are low from pretty much everyone. No one expects you to deliver greatness, and most tech writers aren't invested in the product enough to go beyond the standard expectations.
• Web metrics don't tell you much. Unless you have an excellent method for tracking how users interact with your help, web metrics will be vague and somewhat unhelpful. The last time I checked metrics on one of my help systems, the hits were abysmal. Most landed on the home page and only sometimes clicked one or two content pages. No strong patterns emerged among the hits. Much of the instructional content (e.g., videos) and PDFs weren't tracked, and neither were keyword searches.

Conclusion

To be successful and to draw upon the wisdom of the crowds, the tech writer must move beyond him or herself and incorporate the input of the crowd. But in the end, the tech writer usually works alone.

Next: 3.1 Principles for Organizing Print Material [Organizing Content #21]