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.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

This bothered me. As a good practice, we’ve tried rounding up the kids to read before. But each time this proved somewhat disastrous. The problem is the wide range of ages. I’m 34, Jane 32, Sally 9, Susan 5, and Spot 3. Try holding a meaningful discussion when everyone is at a different comprehension level. What Susan can grasp isn’t on the same level as Sally. And Sally is far beyond Spot, and so on, to say nothing of Jane or me.

The situation isn’t too unlike the problem with technical levels and user documentation. Power users need one kind of documentation, beginners another. It’s hard to satisfy both groups with the same content.

Or so I thought. I haven’t solved the dilemma with user documentation. But with my little family, I’ve learned that story is the common language that everyone speaks. Regardless of age, when you start telling a story, everyone listens.

So we’ve stopped reading by the line. Instead we focus on the story. I read ahead, get the details of the story down in my mind, and then narrate it to my children. Sometimes Jane tells the story. Whereas before Susan would mischeviously close my book, she now listens eagerly. Sally listens and retains the most minute detail. Spot plays quietly with barbie dolls.

When we think about writers who are gifted with language, too often the discussion revolves around articulate expression, the ability to paint vivid imagery, or some other literary talent. Despite these flourishes, the most powerful form of language is story. Story is what has meaning. The stories you tell about yourself, the stories you learn about the world around you, and the stories others tell you form your world view and shape how you understand and interpret nearly everything that happens to you.

Story and Documentation

Story, or narrative, is not a stranger to the world of documentation. As I said, story is the language everyone speaks. In a recent post on The Content Wrangler, Alan Porter says narrative is one principle we can learn from comics and apply to documentation. Alan writes,

The second fundamental of comics is the idea of narrative. Narrative should drive and guide the reader / user along on a journey. All communication is story telling [...] and in story telling your narrative must have a beginning, middle and end. Even if you use a topic based authoring approach like DITA, each topic should be a ‘story’, the reader should be guided through the information and know more at the conclusion than they did at the start.

Alan’s assertion that “all communication is story telling” is a strong one, and much of it hinges on his definition of story. To some degree, a story must have a beginning, middle, and end, he says. He gives the following example of story from Chrome’s comic documentation:

An example of narrative in documentation

If you strip out the visuals and just leave the text, is that story? What really is story beyond simply having a beginning, middle, and end?

To rewrite the above into a more narrative form, it might look like this:

As you surf the web, much of your experience is defined by your browser. But browsers crash when they can’t load scripts or handle the heavy file sizes of websites. Rich media, in the form of video, graphics, and sound, can make your pages load slowly and freeze up your memory. Malicious scripts, worms, and other malware can pass from your browser to your computer, infecting your system with viruses. To avoid these problems, you need a stable, fast, and secure browser. That’s why we built Chrome…

To emphasize the story, I tried to highlight the challenges that you (the protagonist) face when you cruise around the web with your browser.

To be a good story, though, you need several other elements. Good stories start out with some kind of conflict, for sure. This gives the protagonist purpose. The initial conflict sometimes creates other conflicts, which then cross into each other, complicating the situation. The resolution often comes about as the protagonist changes. Without some change in the protagonist’s attitude, stories feel flat.

To make this a good story, then, I would need to talk about the effort to create Chrome, the challenges they faced, epiphanies at moments of absolute frustration, and other flashes of insight that helped make the connections and leaps necessary to build the browser.

Another Approach to Story and Documentation

Although the Chrome example works, much of documentation involves procedural steps, not background on how or why an application was made.

If story is the common language everyone speaks, and the most powerful form of language, what should the role of story be with procedural, step-by-step documentation?

Some procedural topics could actually be written like the example above, setting out the problem and explaining how to solve it through the software you’re providing. Focusing more on the problem is a good strategy. Here’s a page out of the CSS Cookbook that does exactly that:

The CSS Cookbook starts out each how-to topic by defining the problem that the solution answers

Notice how the author begins by defining the problem. The solution then provides the answer to the problem. This problem-solution format is not unique in their approach. Almost every topic in the book is set up this way.

Imagining Persona-Driven Problem Scenarios

Another way to incorporate a narrative perspective into documentation is by imagining specific use cases. Ginny Redish says to imagine not just the questions your users will have on a page, or the types of users who will come to your site, but to imagine specific users with specific problems.

For example, as you’re evaluating the content on your airline site, you may have already defined various personas for your users. But have you imagined your users with specific, real problems? John is a 34-year-old bank executive who needs to quickly cancel his flight to Hong Kong because of a family emergency. Now you have a problem that your content will attempt to answer. Sally is an impatient, scatterbrained secretary who was just thrown into her role last week and has to figure out how to set up a meeting in the new system by tomorrow morning. Again, you have both a persona and a problem.

Additionally, you can also integrate examples of actual users and common scenarios into the documentation. You could describe a typical scenario that Kate goes through to process bank statements in the system and what she does when the transactions don’t balance. This form of narrative is a technique often used in in e-learning.

The Story On and Off the Page

Although I’d like to believe otherwise, implementing story in the traditional narrative form will probably always be a challenge with technical documentation. Story thrives in the literary arts, not in manuals. However, although story might not apply to every page of instructions, every topic in your help can be an answer to a struggle the user is having.

In this sense, the user supplies the conflict and the documentation supplies the resolution. The change occurs when the user’s sense of frustration subsides with an aha! moment. Because of this, we cannot create the full story in our documentation. Instead, we’re only an actor playing a part in a larger story taking place on and off the page — the reader’s frustration with a problem, his or her turn to the help, and the resolution and change of attitude the help topic brings.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Rather than predict or comment on trends in our industry (which I already did here), I’d rather describe the actual directions I’m going in 2010.

Embrace a Collaborative Authoring Platform

I’m embracing collaborative authoring this year, with plans to entitle key authors in various departments for some projects and completely open up authoring for others. More and more projects I write documentation for require input from multiple subject matter experts spread out across the organization. The days when a single writer could accurately provide help for people in a department he or she isn’t even in seem to be over. I’m planning to use Mediawiki as the collaborative platform (because it’s on the menu of approved technologies in my organization). A collaborative authoring platform will also simplify interactions and exchanges when I have teammates working on the same project.

Let Customers Own the Documentation after the First Release

This year I’ve noticed another trend: customers want to own the documentation after I write the first release. When this first happened (and someone requested my source files), I was offended. But the more I thought about it, the more it made sense. As I write documentation for more and more projects and departments, I’m building a larger base of documentation to maintain. I can’t be effective when I’m maintaining fifteen different projects at once while working on three new ones. I prefer to have a dedicated handful of people with authoring capabilities to help with the maintenance. That just isn’t feasible with a proprietary and costly help authoring tool (in my situation), so this direction builds on my previous point about embracing a collaborative authoring platform.

Make Screencasts a Core Deliverable

The best feedback I receive about my help deliverables is with the screencasts I create. I plan to continue screencasting, perhaps dipping more into dynamic visuals with Adobe After Effects or Flash. I want to further hone my audio and visual skills in this medium.

Continue Team Design Reviews

In our agile environment, our team is spread out across various portfolios and departments. We lose out on a lot of interaction and camaraderie, but we recently started doing some biweekly design reviews in which we get together and critique each other’s help. The design reviews have been engaging and worthwhile – I hope we continue them regularly into 2010.

Participate More in Design

One of the situations I dislike is 9^th inning documentation. At this stage, the interface is frozen and I’ve been such a stranger to the project that the PM isn’t looking at me for any input other than to document “what is.” Instead, I’d like to make it my standard to get involved around the 4^th or 5^th inning so that I can contribute more to the interface and task flow. One reason I haven’t been able to jump in this early is because I’m so busy maintaining documentation for numerous projects that are in their second or third release cycles. Getting involved early with the design and earning a seat at the design table will require me to prove my worth, certainly, since we already have a fair number of interaction designers, business analysts, and project managers who perform this role.

More Story-Driven Blog Posts

On my blog, I plan to write more story-driven posts. I get more response and fulfillment from blog posts with well-crafted narratives than I do anything else. My daughter recently listened to about 12 hours of Storynory podcasts straight because of the mesmerizing power of story. I want to develop my skill at seeing story and building narratives that engage audiences.

More WordPress Consulting

I was a bit wishy-washy this year as to whether I would continue WordPress consulting or not, given the time it consumes. But I love working with websites, and the extra money helps, so I plan to do even more WordPress consulting in 2010. If I get too much work, I’ll outsource some of the development (I already outsourced much of it last year). This year I’m specializing in Woothemes more, since it seems to simplify the client’s decision-making process with themes.

More Basketball

For many years I’ve felt guilty about playing basketball. Compared to other forms of exercise, basketball takes three times as long, causes me to stay up too late, and seems to be an inefficient way to get exercise. But I’ve finally decided to succumb to it, because I love playing it and because life in IT is so sedentary. This goal feeds into my overall New Year’s resolutions to do more of what I love.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

We all sat mesmerized while Hymas related story after story. His speech wasn’t polished or his diction articulate, but his life-altering stories held me at full attention. As I walked back to my department, I wondered how he had become a motivational speaker. Was it the handful of life-altering stories, which he could deliver in sincere, moving ways, that made him inspirational?  I thought, perhaps if I had a handful of life-altering stories …

But later I realized Hymas probably didn’t have more stories than anyone else. There are hundreds of other quadriplegics, others who have broken their necks, who are no doubt dull, unmotivating, and ordinary.

What separates extraordinary presenters and writers from others? I believe it’s the ability to see stories where others miss them. The ability to create stories where others look at the obvious and see nothing.

Writers see stories where others see nothing

This week I’ve been reading a book of essays by James Hall, a contemporary Florida novelist. In one of his essays, Hall explains how that his love for reading stemmed from a murder mystery called Nude Woman in the Grass, a book he randomly found in the library and started reading when he was ten. The smutty-sounding title (which turned out to be very PG) grabbed his attention, but he found the mystery gripped him, and led him to see the appeal of reading. He writes,

“So this was why people read! Books were about adult things. Strong emotions, extreme behaviors, the inside stuff of a world I had never imagined existed. In this my first recreational book I suddenly realized that novels could fill one with heart pounding fear as well as lip-smacking lust. That they could, in fact, suddenly expand the boundaries of the tiny hillbilly town where I had always lived and where I imagined I would always stay.”

Hall’s experience was quiet, subtle, and mostly stationary — he was merely reading a book in a library. But within this one moment, he sees a larger, more meaningful narrative.

The writer’s ability to see story where others pass it by is similar to the photographer’s eye. When I take photos, I merely point and click, and don’t think much about what I’m doing. But real photographers, I’ve been told, look for the single moment that tells a story — the one split second where someone’s countenance tells the story of the whole. Novices don’t see this. The captured moment is something you must learn to see. The photographer sees the invisible story and captures it.

Yesterday Jane and I rode our bikes through some winding roads in Eagle Mountain, passing by rustic 9,000-square-foot ranch homes, many with horses in the sides of their yards and four car garages. The sun was setting over the mountain hills. I was pulling all three kids in a bike carrier behind me.

Nothing happened on the ride, but I felt, in a few distinct moments, that we had found a place we could call home. After years of living all over the world, and months of searching for the right place, we found the right place.

I started to see how I might create a story out of an experience that didn’t seem to include a story. We were, after all, just riding our bikes. No one was injured. No one broke world records. No one even talked much. But I caught a glimpse of the narrative that was going on, almost invisibly before us.

——–

photo from SAAO

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree