As with any new skill, it’s one thing to learn about it and think about it theoretically and another thing to put it into practice.
In my work, I get to write many styles of documentation from informal, internal user guides to formal, highly regulated, auditable process instructions.
I’ve found it easiest to practice what I’ve learned about technical storytelling when I have the ability to use a more personal tone. I have great examples like Intuit’s microcopy in TurboTax building relationships with users, and MailChimp’s high five from Freddy each time you send an email campaign. Both are really great examples of how the software plays the important sidekick role to the user’s hero journey, and builds a personal relationship in the process
But I still get stuck when the content is more about fulfilling an (important) box in the regulatory process than delighting my users. Adding dialogue or writing to establish personal relationships with the users is not proper or allowed.
However, I know how powerful storytelling is. It makes facts memorable and connects to people’s emotions, affecting learning and decision making. Just because it’s not appropriate to use storytelling techniques in the content doesn’t mean I should disregard storytelling completely.
So what’s a writer to do?
If you can’t tell the story IN the content, tell the story AROUND the content.
Two ways I’ve learned how to tell stories about the content are customer journeys, and telling your team customer stories.
A customer journey is the map of the actions a person takes to perform a task or otherwise interact with your company, product, or service.
Too often, people forget the “journey” part of customer journey map. Every story is a journey, the user the hero, and your product the sidekick. How is that person changing?
Focusing on the What is like only looking at the symptoms. Storytelling helps you get to the root of behavior by focusing on the Why and how they can satisfy their goals, needs, desires, and expectations.
A couple years ago, I created some basic training for some sites I manage. Recently, I looked at the basic training through fresh eyes. My customer journey had only focused on the tasks the user needed to accomplish. I re-analyzed my customer journey by thinking in terms of a story, and found a number of areas that I could improve. I’m now in the process of re-writing some of those help topics and getting feedback on how much more complete the training is.
The other day I was reading Twitter when I came across this post by Paul Boag of Boagworld:
“Tell the customer’s story. Some respond to data, others to stories. Talk about your customer’s struggles, it will help colleagues empathise.” (Tweet July 3, 2017)
It occurred to me that all my efforts are on outbound communication FROM me TO the customer. There is an inbound element in user research and analysis, but in general my focus is outward. I don’t think I’ve ever truly told customer stories to my engineers and SMEs.
A coworker, however, used customer stories to help approve a project. The project had been in limbo for almost a year. Various meetings and presentations between people had only slowly progressed the project towards approval. We had recently been discussing technical storytelling and she decided to make a case for the project by focusing on customer stories supported by data. It worked! There were still some minor hurdles to overcome, but managers approved the project.
Sometimes, storytelling within the content is not permitted or appropriate. In these cases, consider telling the story around the content instead. Two ideas include creating more robust customer journeys, and telling the customer stories inward to other people in your company.
How else have you told stories in regulated situations? Have you shared customer stories internally? Storified your customer journey? How did it work? I’d love to hear your story!