I’ve put some thought lately into the idea of incorporating more narrative text in my documentation. I’m a fan of stories myself—aside from the fact that I enjoy adventure books. When I’m listening to a speaker or reading an article, I mentally perk up when what is apparently a narrative comes along. Narrative grabs my attention.

Why couldn’t I do the same thing in my technical writing? I have, to some extent. One manual I’ve written contains examples that are set apart in the text rather than being introduced with wording like “For instance.” I did it as a mechanism to show how a possibly real-world situation applies to the software I documented. I wasn’t really thinking about the narrative itself, though.

When I was a writing tutor in college (Look! There’s some narrative now…. Come to think of it, the previous paragraph had some, too….), I’d tell students that narrative is an effective writing tool because people identify closely with it. It’s a core part of our linguistic abilities. Whenever your colleague asks you what you did over the weekend and you tell him, you engage in narrative.

Once Upon a Time…

Joan: Hey Paul, have a good weekend?

Paul: Yup.

Joan: What did you do?

Paul: Well, first I chased some wild coyotes out of my basement. I let them stay there over the winter, but they wouldn’t go away once the sun started shining, and they were crowding the badgers, which have been there since before I bought the house. So I got rid of them. Next, since my friend’s always saying he lives a stone’s throw away from my place, I threw a rock into his yard just to prove it.

Joan: Sounds eventful.

A narrative isn’t defined as a block of text that begins with “Once upon a time” and ends with “and they lived happily ever after.” It’s any text that speaks of past events, even if they’re fictional. (Narrative can also be in present tense, but that’s probably not an effective style for technical writing.)

Narrative Is Like Your Shadow

I stick by my earlier explanation of why narrative is an effective form of delivering information. Because we engage in narrative every day, we are intimately familiar with it. We understand how events relate to each other as one comes after another.

Thus, using narrative forms can help our users understand complex business principles and procedures. Step-by-step instructions obviously reflect a chronological order, but sometimes it’s only when we place the procedures in an even more familiar form that users truly grasp the ideas.

It must have been this concept that drove the format of books such as Leadership and Self-Deception by the Arbinger Institute and The Wealthy Barber by David Chilton. The Wealthy Barber is essentially a finance textbook put to dialogue, which made it nearly unbearable to read as a story. However, it did put finance principles in a format that made them easier to understand as the title character explained to a few of his friends—and to the clueless person reading the book—how to get some financial security. Being a writer myself, I was probably bothered by the structure than most people.

Leadership and Self-Deception was better, since the story didn’t consist entirely of a series of conversations. A couple of characters did discuss certain principles with another, but then he had some internal struggle and also went home to see if he could apply the principles to his troubled family situation. It flowed better than The Wealthy Barber.

I’m not suggesting that narrative should take over your technical writing. The idea is to insert some here and there where you think the user may need a little extra help understanding a workflow or concept. If you’re using an electronic format, you could even put the narrative in an expanding hotspot so that it is viewed at the user’s discretion (an idea I adopted from Tom Johnson). For some users, narrative text may provide just the key to make things click.