Narrative and Fact in Tech Comm

Based on the responses to my post Topic Size: Finding The Narrative Minim, I think I need to say a little more about what I see as the role of narrative in technical communications.

To set the stage with broad brush strokes: The purpose of technical communication is to enable action. Technical communication gives a person the information they need to act confidently and with success. Just how much information each person needs in order to act depends on how what they lack. Some need a word; some need volumes.

Our tools to address these needs are facts and narratives.

key and letter

A fact is like a key that opens a familiar door for the reader. Free image courtesy of FreeDigitalPhotos.net.

A fact is a single point of data. A fact is like a key that unlocks the door that the reader is already standing in front of. They know what is behind the door. They know why they want to open the door. They know what is going to happen when they open the door. They just need the key.

A narrative is an orchestrated and annotated parade of facts. A narrative is like a tour guide who takes a passenger on a journey through parts unknown, providing advice, context, translation, and reassurance. The tour guide brings the passenger through unfamiliar streets, leads them up to the door, explains what is behind the door, why they should (or should not) open it, and what will happen if they do (or do not) open it.

Writers often puzzle over how to construct narratives. Users are diverse — how do we make sure the narrative serve all of them? Do we make one big narrative for all, or do we break down the content into smaller and smaller pieces in the hope that each reader will be able to string together whatever narrative they need for themselves. Whatever scale of narrative is proposed, there is always an argument for making it bigger, and an argument for making it smaller.

3D image of a journey

A narrative is like a guided journey. It takes the reader to a new place.

In a perfect world, the tour guide picks you up at your door, and leads you personally from your starting point to your destination, serving you alone, and always stopping to answer any questions you have or to take any detour that interests you. That is what every writer would love to be for every individual reader.

In the real world, a tour is arranged for a group, it meets at an agreed location, usually a port or airport. It attempts to meet the aggregated needs and tastes of a typical group of tourists. It allows for few deviations or private explorations, and describes the passing scene mostly from a standard script, with few opportunities for questions. It may take you to the city, or even the street, but it seldom leads you all the way to the single door of interest to you. On the other hand, it may recommend several good guide books should you wish to leave the tour and explore on your own.

A technical conversation between two people may sometimes approach the ideal, but even then, as anyone who has spoken to tech support knows, most of the time the support person is reading scripted answers and is helpless as soon as you ask an unscripted question. For the most part, technical communication is a bus tour, not a private travelling companion.

airport

Like a group tour, a narrative should depart from a sensible public place, not each reader’s front door.

Tour operators do not offer to pick every passenger up at their homes. They designate a meeting place and leave it to the passengers to find their own way there. They choose sensible places for meeting; not a street corner, not 35,000 feet over the Atlantic, but at the airport.

So it is with narratives. They serve many readers, and they pick the reader up at a sensible place. They leave it to the reader to get to the departure point, though, like an airline, they may also offer a connecting journey via another, separate narrative. It is not the job of a narrative to provide concierge service to every individual reader. The job of a narrative it to provide efficient transportation between two hubs. The job of a collection of narratives is to provide an efficient transportation network that enables many different readers to accomplish many different tasks while sharing each leg of the journey with many other riders.

There are two ways that technical documentation can fall into disarray. One is to become a unthreaded jumble of facts, leaving every reader to make sense of everything for themselves. The other is to attempt to pick every single reader up at their door and deposit them exactly at their destination, while forcing every one of them to ride the bus the whole way through every pickup point to every drop off.

Creating an information set, therefore, is rather like designing a transportation system. Every reader’s journey is unique, but the system runs service between hubs. It is the reader’s responsibility to get themselves to the hub (which they may do by using ancillary information networks). While this does not always move the reader by the fastest or most direct route, few can afford to travel by limo and private jet. A transportation network that provides regular service between well chosen hubs provides overall the most efficient transport for the masses. An information set should work the same way.

Airline route map

A well designed information set is like a well designed transportation system, it allows passengers to travel individual itineraries along shared routes.

This then is how you devise a narrative. You don’t worry if it is the ideal size for each reader individually. You design it to run between a sensible pick up point and a sensible drop off point, and you provide information on the connections to related narratives on which each reader can continue their unique journey. You do not daisy chain every fact and scrap of narrative into one vast hierarchical Frankenbook. You create a navigable network of sensibly sized narratives with sensible end points.

Of course, your network will not be complete or perfect. It will not cater to every journey. Some routes are not traveled often enough to make regular service economical. Sometimes readers will have to find their own way.

This is where facts come in. It’s not that readers are entirely stuck if we don’t give them the right narrative. People are, in varying degrees, smart, brave, determined, and patient, and if they can scrape together enough facts, they can construct a narrative for themselves. Some among your user community positively thrive on the challenge (and, as a bonus, they will often leave a map of the route they have taken for others to follow).

But even the bold and the brave, are at a loss if they can’t get at the facts. References, then, are fundamental; the foundation on which an effective documentation set is built. Facts should not be buried in dubious narratives were they are less discoverable than in references.

Even the reader who needs only the key to the door before which they stand, still needs the collection of keys to be sorted and labeled. Presenting them with a box of miscellaneous keys, or, worse, a bunch of miscellaneous junk among which there are keys, does not enable them to act confidently and with success. It sets them up for much tedious searching and trial and error.

This then is what the ideal documentation set should look like: a foundation of solid well-organized database of facts upon which is built a highly navigable network of sensibly sized narratives connecting sensible hubs.  References are databases. Topics are narratives. This is how you know how big each of them should be.

One Response to Narrative and Fact in Tech Comm

  1. Marcia Riefer Johnston 2012/09/20 at 12:49 #

    Excellent analogy, Mark. Beautifully written. I’ve often thought of modular (topic-based) writing as analogous to signs in an airport. When you want to get from Gate B to Gate X, you don’t want to study the whole map; you want just that route. The closer we writers can get to anticipating the routes that people will need help with, the better decisions we can make about “narrative minims.”