Technical Communication As Story Telling

Over on his "I'd Rather Be Writing" blog, Tom Johnson, has taken my idea of Tech Comm as storytelling, and expanded on it an excellent post, that I highly recommend.

In particular I like these two ideas on the practicalities of applying story telling techniques to technical documentation:

THE ELEMENT OF CHANGE

In a good story, the resolution always brings about some type of change, or comes about because of change. If you listen to stories on The Moth podcast (a storytelling podcast), you’ll constantly hear this element of change near the end of each story. For a story to feel meaningful, the protagonist always changes as a result of the conflict. Without this element of change, the story feels flat.

In technical documentation, achieving that element of change is difficult. In almost all technical documentation, the reader is the protagonist, since our point of view is second person (“you”). You (the reader) have a problem. ..... Through the help topic’s steps and information, you find a solution that solves your problem. Hooray, you’re much happier and complete now. That’s the basic transformation.

And..

FOCUSING ON THE PROBLEM

A problem of some kind usually drives and gives rise to the story. But isn’t every help topic by default the answer to some problem? And aren’t users coming to the help content with a problem already in mind? Do we need to explicitly supply the problem, since it’s already apparent in the user’s mind?

Yes, your protagonist already has a problem. That problem is what is fueling his or her path through the help. But it can still be helpful to state the problem explicitly so that users can connect their problem to the solution you describe.

In many ways the examples and ideas that Tom cites, also feedback to my earlier post on Applying the 10 Commandments of Storytelling to Technical Documentation.

It's great to see these ideas being picked up and expanded upon.