Storytelling is probably as old as our history. And, stories are the commonest way the ethics, histories, information, insights, and knowledge have passed on to the younger generations. Through its multiple forms, such as cave paintings, dance forms, hieroglyphics, oral narratives, and scriptures, storytelling focuses on building touch points to get messages across; Something that we too do as technical writers.
So, what things does storytelling have in common with technical writing?
First. It lends the eternal assumption that a seeker – the common term for the user, listener, or reader – acquires knowledge from the stories: The knowledge that helps them move from point A to point B; the knowledge that graduates their understanding about something; the knowledge about non-knowledge (or absence of knowledge); or the knowledge that the human co-existence is a factor of information co-existence.
Second. Stories and technical writing have more than a thread in common: The underlying messages can apply to anyone and everyone. Both stories and technical documents can be interactive; can contain data, facts, and information in either interdependent or independent form; and contain varied granularities of information. Novels, if you see, are as exhaustive in information as technical documents. The messages take up different forms, such as graphics and words, too.
Third. The assumption of not assuming. Though it is true that the seeker intends to acquire knowledge, it is not good to assume that the seeker does acquire knowledge. The seeker may already know something, yet not know that they know it! But, this assumption of not assuming lends us a deeper insight. As technical writers, we write what we observe; we do not opine. We just record and report what happens. We let the content remain objective and undistorted.
Fourth. Borrowed knowledge (which is the knowledge that is learned from other’s experiences) influences the story and its underlying messages. On some occasions, such a knowledge will help consolidate the messages for definitive conclusions. But on others, it may dilute the interpretations with parallel conclusions and myths.
This is because each of us builds understanding based on filters: Just as we filter any information to make sense of it, we filter problems and solutions, too. This filtering is subject to our point of view. And, as technical writers, we must not blend our opinions with our observations. Cross-referencing, premise-building, and verifying the borrowed knowledge can help extend some relief, though.
After all, referencing is how we co-create information. We co-create information structures by cross-referencing to someone else’s information and facts. And, these information structures, which I think are stories, help create dependencies for our co-existence.
Fifth. Research can help bring the absolute knowledge – which is not subject to situations – to the surface. But, it is sometimes the impact of non-knowledge that counts. If you too have read Panchatantra – a series of interwoven fables – you will know that the experience precedes the commonsensical approach. This commonsensical approach is the absolute knowledge in the case of the stories in Panchatantra.
Sixth. Perhaps, the most important contribution of storytelling is transformation. Stories help us relate to and compare the current scenarios to past-previous experiences. The decision-making process speeds up because our comparison transforms data into facts, facts into information, information into knowledge, knowledge into wisdom, and wisdom into conclusions and decisions.
This is like a domino effect: The transformation of data into wisdom triggers the transformation of assumptions into solutions and problems into informed decisions. That’s what we, as technical writers, do: We transform complex technical information into usable chunks of knowledge. But, this learning comes to us in two parts, both of which are important: say the correct thing and say the thing correctly.
Right, so we all agree that, to an extent, storytelling and technical writing have more than a thing in common. But, where’s the point in the argument?
The point is experimentation trumps information, at least from where I can see. None of the SMEs or product users I interacted with have read manuals before they began using our products. Even we, as users, prefer following habits and instincts over following the documented information. And, this approach makes me think about designing technical documents that are easier to read, understand, and use.
Both technical writing and stories have words. Words, on their own, do not convey meaning. Words contextually convey intentions. Intentions drive our instincts, and consequently our actions. Actions create patterns, and patterns create designs. As a definitive conclusion, I realize that intuitive, commonsensical information designs trump technical documentation. Such designs are easy to make sense and relate to, remember, and recall.
But, if we follow these insights do we not become storytellers? Well, I leave this question up to you. I follow these insights so that I can think the way my readers think: I seek the way they seek any information. And, I still remain a technical writer; just that I am able to get the correct message across correctly.
As I approach the end of this post, I am able to raise as many questions as I am able to find answers to:
- A story necessarily has a journey, a plot, or a sequence (structure?) of events that happen one after another. How does that apply to technical writing?
- Can information be independent yet co-existent?
- How does a narrative differ from a story? What is the relation between the two?
- How is storytelling different from technical writing? For example, how does the golden rule of knowing your readers apply in storytelling?