Story (Overlooked)
Now I have a confession to make. I really didn't want to talk about roles and hats and value. I wanted to talk about story. But I didn't want to talk about story directly. Instead, I wanted to illustrate it by structuring my entire presentation as a story.
You've seen that with each of the headings, I labeled a component of the story. I began with a problem and a yearning, and moved through a series of catalysts that brought about change, ultimately leading to a crisis point that presented a crossroads, and finally an epiphany and a resolution.
Whatever role we play, our core deliverable, our most important contribution will probably still remain the written word. For the most part, we are writers. I said at the beginning that many organizations feel that "anyone can write." When you focus only on grammar and style, on rhythm and diction, on correct punctuation and format, then ultimately it's true: any literate person with a college degree can do a good enough job to pass off as a competent writer. But good writing is more than the text. Good writing is story. Story is the magic formula that makes everything work.
When we think of story, we often think of novels and fiction. Conflict, change, and resolution. But if you loosen up the definition of story a bit, you can see its application everywhere. When a user encounters a problem and attempts to find a solution, that's story. Good stories also involve the element of change, but even flat stories (without much change in the characters) are still stories.
When we write blog posts, or marketing material, or give presentations, it's easy to see how to implement story. You paint a picture of the problem that you or the user are up against, the complexities and attempts to solve the problem, and finally the resolution.
But writing documentation also follows a similar process. You get inside your users' heads and think about the problems they're trying to solve. Not only the problems they're trying to solve, but the problems they'll run into with the application as they're trying to solve the problems. The solutions you find and present will provide the ending to the user's story.
You have all the elements of the story in technical communication: motivation, conflict, change, and resolution. It's not just a model for fiction writers. In fact, Whitney Quesenbery and Kevin Brooks have just written an entire book called Storytelling the User Experience. Whitney sent me an advanced copy that I'm reading now, and it's fascinating. Early in the book, she quotes Ira Glass, host of This American Life, to explain the power of story:
Until you hear a story and you can understand that experience, you don't know what you are talking about. There has to be a person's story that you hear, where finally you get a picture in your head of what it would be like to be that person. Until that moment, you know nothing, and you deal with the information you are given in a flawed way.
Not only will our communication be ineffectual without story, without understanding our users' stories, we won't be able to know what to communicate.
Carry the story mindset with you in any situation -- not just writing the documentation, but in designing the user interface, in creating test scenarios, in presenting training to users -- and you will see your writing take on a whole new life and energy. You will become a better writer, for sure. But more important, when you involve story, you will also become better at whatever role you play.
