Does Storytelling Work in Technical Documentation?
Four Reasons Why Nobody Needs Storytelling
Technical documentation can be mind-numbingly dull. You are bound to the same process every time, you never get out, you write uninteresting texts that seemingly anyone could devise- No one reads it and no one understands it, all adding up to a total waste of paper.
Yeah. It’s a bummer. So now we aim to tell stories.
But, let’s be frank: Everything these days seems to trend toward storytelling. There are countless lectures, seminars and articles surrounding the topic. Books and literature on this subject constantly come out of the woodwork. This raises the question of how much value storytelling necessarily brings to the table. Is it really the one-size-fits-all answer to effective communication its recent attention seems to suggest? After my time working intimately with the theme of storytelling, all I have to say is: it’s terrible.
1. There’s No Way Around it: You Have to Choose the Appropriate Method
There is truly no shortage of ways to tell a story. A classic approach would be the “Hero’s journey” we all know from the media in our everyday lives. We meet it again and again, be it in the books and films of Harry Potter or the Stanford speech given by Steve Jobs. Pixar follows builds its own story formula with generic phrases like “Once upon a time …”, “One day …”, “Until finally …”. We could go on.
Not all methods are suitable for storytelling in documentation, though, since the texts often end up excessive. However, these two methods can be applied effectively, for instance:
- The before and after comparison, also called the “before and after bridge” (original state, better state, representation of the function)
Example: With the manual version, Sarah needs 17 clicks to complete the package. Now that she’s been using Auto-Packaging, she’ll get exactly the same result with a single click. And this is how it works …
- 3-file structure (initial situation, conflict, solution)
Example: Sarah wants to assign tasks quickly and accurately. Until now, this has always been done manually, which takes lots of time because she has to reinvent herself every time. She remembers that she had heard from her colleague that there was an automatic function for this. She tries it out immediately and is thrilled. And so on…
This allows you to invent short stories that are precisely tailored to the reader’s current needs.
The more complex LEAN storytelling is suitable for the analysis of a story in order to improve it afterwards. This means that the story follows a learning loop with the recurring points: writing, telling then learning. In this way, the feedback continuously refines the result.
2. You Also Have to be Interested in the Target Group.
That’s awful, isn’t it? You’d love to go back through the subtleties that you’ve worked so hard to develop over and over again, so much so that you’ve almost beaten them out of the developer. And now all of this is meant to be packaged AND simplified so the reader can functionally do something with it? Let’s take a simple example: the weather forecast. If it were to say “Tomorrow it will be 19 degrees”, would you understand what to wear? Maybe it’s raining? But if it then says: “Tomorrow it will be 19 degrees, sunny and cloudless”, it is already clearer to you that it should probably be T-shirt weather. The reader can actually do something with that.
In short, the target group is always important, but in storytelling in particular you have must understand it. That’s not always easy.
3. The Potential That Readers are Able to Remember the Information Increases Enormously
Remember when you threw your last manual in the corner, never to be revisited? Do you recall how angry you were and what absolutely useless information it contained? Or how you searched the FAQ for something and found only a tutorial that didn’t fit the topic at all? These are all events that provoke negative emotions. And, as you probably just noticed, they stick with you. Information that is imbued with vibrant emotions is memorable. Instead of driving the reader crazy with the wrong information at the wrong time, useful information in the technical documentation should be packed with positive and affecting emotions so that it sticks in the reader’s memory.
4. You Can Develop Common Concepts, Though This Means More Work for You.
Let’s say you choose storytelling and develop a protagonist. That’s hard work. So, why coordinate with your colleagues or even other departments now? Just so that they can throw in their two cents and muddy it all up again? You can also simply trust your concept and believe in it blindly. I’m certain everyone will take heed and recognize your genius.
But of course it’s not like that. Storytelling can only be a success if you coordinate, get feedback and allow for other perspectives and ideas. Then the whole external communication can be based on a singular protagonist or concept and developed further. This helps to build common terminology that can have positive effects on SEO. Or- would you like your protagonist to end up as a negative example in the lectures, like the paper clip of a fairly well-known software manufacturer?
Long Live Storytelling!
Perhaps you have already noticed that this article might contain trace amounts of irony. Storytelling has its advantages and disadvantages. It doesn’t work for every product and certainly not for every target group. If I tell a service technician that repairs defective gas heaters a story in his documentation about what problems might occur, it’s just not appropriate to what he’s attempting to do. But if he then tells the customer receiving his service that his last customer who didn’t do it ended up in a hospital with carbon monoxide poisoning, it will surely be remembered.
- Does Storytelling Work in Technical Documentation? - 14 February 2019