Too little information

Were I asked to characterize the human condition in a sentence, I might choose this: to be human is to make decisions with too little information. All our decisions, great and small, are taken without adequate information: getting married, buying real estate, having children (this especially), saving for retirement, choosing the best route for a journey, taking a job, or hiring an employee. We don’t know nearly as much as we would like to in making any of these decisions.

In great matters of state, it is the same. Going to war (or avoiding going to war) is a decision that is always made with too little information. In the great debate on global warming, decisions of enormous global economic and environmental consequences are being made in response to disputed claims and in the face of a very mixed history of past predictions of catastrophe. If we wait until we know more, it will be too late to act; if we act precipitously we may do more harm than good. This is life: making decisions with too little information.

That, certainly, is the life of a technical communicator, a profession that might well be described as writing about a product you don’t have enough information about for an audience you don’t have enough information about. For many departments, shrinking budgets and accelerating development schedules force us to act more and more without the information we need to make good decisions about what, how, and for whom we should write.

In most aspects of our life, we take specific and deliberate precautions to compensate, as far as possible, for the fact that we must make decisions with inadequate information. The marriage vow itself is a an acknowledgment of, and bulwark against, the unknowable future: sickness or health, riches or poverty. In investing, we diversify our portfolios. In politics we make alliances and maintain reserves. In our cars we keep a jack and a spare tire.

But I wonder how good we are in technical communications at compensating for our lack of information. We talk a great deal, of course, about ways of getting more information: about conducting customer surveys and visits, about developing personas and use cases. We devise ways of getting more information from developers, and campaign to be included earlier in the design and development process. And these are all good things, but none of it can come close to providing us with perfect and complete information. And, of course, it all costs time and money. And, since our resources and our time are finite, all the time we spend on information gathering is time we don’t spend writing.

In the end, simply trying to get more information is not a sufficient strategy for dealing with the fact that you must make decisions without enough information. Finally you will run out of time and resources in the quest. And you must leave yourself both time and resources to actually act on the decisions you make. Knowing when to stop researching and start writing is an essential part of the business.

But there is more to it than this. When faced with choosing and acting with inadequate information, we should strive as much as possible to keep things simple. Simplicity is robust. Simplicity is flexible. One of the watchwords of the agile software development movement is “do the simplest thing that works”. Every day we get new information, and if we have kept our work simple, we can adapt more quickly to that new information.

In technical communication, the simplest form of information is the topic. A topic is short, simple, and compact. It does one job. A collection of topics is a very flexible thing. Topics can be added, removed, or changed, as circumstances dictate and the information available to us changes.

Unfortunately, while many organizations have made the move from books to topics, it seems to be coming all too common to create elaborate and complex information architectures in which the simplicity and flexibility of the topic is compromised or lost. Rather that doing the simple thing of creating a collection of independently viable topics, some organizations are mapping out complex information hierarchies into which topics are then written to play specific assigned roles. Topics lose their independence and are written to play a specific role in a specific information architecture — an architecture built, as all things are, with inadequate information.

When every topic stands alone — when every page is page one — then the reader has as many entry points to the collection as there are topics in the collection. Those topics may all be written without adequate information about their intended audience, but in their sheer multiplicity and variety they provide the diversification that makes a good portfolio resilient as the market rises and falls. And for the writers, writing independent topics as if each were page one, leaves more time for writing, while making each individual writing project a simple one for which a much better estimation of the quality and reliability of the available information can be made. When writing a topic, it is much easier to decide when to stop researching and start writing.

We live and work in a time of great change, particularly a time of great change in the way in which people seek, receive, and consume information. The desire to experiment with elaborate new theories of information structure and design is certainly understandable. But it is also highly uncertain, and we still have jobs to do, readers to serve, and shareholders to satisfy with the basic soundness of our contributions to the product we document. In this environment, keeping it simple is the wisest response to the uncertainty we face. And there is nothing as simple, as robust, as resilient as the independent topic residing in a collection of topics in which every page is page one.

, , , , ,

Comments are closed.