The Story-Telling Trend

I was having coffee with someone yesterday to talk about his project, and I mentioned my background in creative writing, which led us to the current craze about story-telling.

There is even a med school program with a focus on storytelling for physicians, narrative medicine, which I think is such a great idea. Most doctors I’ve had couldn’t even listen long enough me to give them one sentence of information about my symptoms.

The gentleman yesterday had come to me knowing little about tech comm. In fact, he asked me about the term, “tech comm,” which he had seen sprinkled liberally throughout my blog. “Tech comm” is jargon for the industry of technical communication. Or, if you prefer, stories about using products.

He and I even laughed about his ad agency, which, sure enough, was touting story-telling as their focus. So is story-telling for products a stretch? Actually, no.

A five-step procedure might be technically accurate and pass QA, but a story-teller looks for signs that her audience is engaged. A good story is remembered and can be retold. This could be as simple as writing a short description that places the procedure steps in context. It could be examples. I’m excited to see what else it could be. I think this trend is gaining momentum.

All things being equal, hire the person who can write or speak the best. By definition, that means in story format. I recommend this for two reasons: a person who can tell stories can communicate with and motivate others, they can help define the narrative of the work they’re performing and plan to optimize that narrative, and they can do the same for themselves.

For me, that’s the main benefit of this blog: I tell myself the story of my career. When I take the time to articulate my experiences to myself, I can learn the most from them.

So, I’m a believer in the power of story-telling, even for specs and instructions. It’s just amusing to me that this isn’t obvious, and that companies can generate so much buzz by juxtaposing the term with their own industry jargon.

How Real Do We Need to Get about Our Documentation?

Our team has been working on reorganizing our template for help system content, and last week we showed it to clients in an online demo. We also went on our first-ever client site visit to a hospital that uses our laboratory information systems. The lid is off Pandora’s box.

We’ve been asking to get our hands on clients for years. When we got our new manager a year or so ago, she led an organized effort to this end. We were told to use internal resources, first. So now we receive the relevant emails from the user listserv. And the irrelevant ones.

We were told to comb the knowledge base for things that ought to be added to our manuals. My product alone has almost 200 articles. My plan is to categorize them and prioritize them so I can start incorporating the information. But it’s overwhelming.

I started asking around about getting access to demographic information on clients from the marketing database, and was told to watch my step in that inquiry because that information is fiercely guarded. So I’m saving that task for a day when I feel especially crafty.

The help design project, though, was an opportunity to talk directly with the clients. Ostensibly, we wanted their opinions on the prototype. But it was also an opportunity to chat about what they do all day (it was mainly a group of system administrators, who test the system and make sure everyone is using it correctly). By coincidence, we were scheduled in the same week for the standard hospital tour that our tech support new hires get. It was a chance to ask a boatload of users what they think of our current help systems.

They don’t think much of them, that’s what.

The system administrators use them when they absolutely must. The end users (technologists, phlebotomists, lab managers, nurses..) all ask the system administrators when they hit a snag in the system. Period.

Admittedly, I’m generalizing from one site visit and and one call with 15 sys admins. But this is 100% more information than we had the week before. I think we’ve got some solid areas to test. Such as: how long does it take for an end user to solve an issue in the system if they look it up in help vs. how long does it take if they call the sys admin and ask for help?

There seems to actually be resistance to end users using help. “They don’t have time to be clicking around in the system.” Should we be advocating for help use or should we give it up and write directly to the system administrators; give them more tools to help the end users themselves?

I cringe now when I think about how many heated discussions we had over verbiage that no one is going to read and links that no one is going to click.

A team member had a good question: how are we going to reconcile all this feedback (part of the new help design incorporated even more client feedback features) with the standards we’ve worked so hard to develop? Is there going to be push-and-pull there?

Our manuals are huge. Our systems are complex. We want to have time to incorporate video and be responsive to feedback. How real do we need to get about what we can leave out?

Introducing HD (Help Design)

One day a long time ago, in our staff meeting, our new manager referred offhand to our new mandate: that help systems shall be our primary deliverable. Print manuals shall take a back seat. Or maybe I referred to it when I said we should have topic templates. Or maybe that was when someone suggested that we streamline some of heading phrases that we use throughout our documents. What I clearly remember is that our manager asked for a few volunteers to meet as a committee and come up with suggestions as to how we could optimize our content for online help.

This week, I went digging through our old SharePoint site to figure out exactly how long ago that was. I was afraid to look, and rightly so. In March, it will have been a year and a half. Oh, and we will still be going in March, meeting with team members as they start to implement the new format and designing training exercises. We’re presenting a prototype to clients and programming this week, and we’re finally in implementation phase, but—a year and a half!

So begins the story of my first time leading a group project. Three SharePoint sites and roughly eighty meetings later, the project that has come to be called “HD” has taught me so much. From the outside looking in, the pace may have seemed glacial, some of which is a result of our inexperience and some of which is just the standard pace of change in a large, hierarchical company when many departments are affected, but we have had our hands full the entire time. I don’t think the same project would take us as long today, and I’d like to figure out why—where did we stumble? What did we learn?

I had some general ideas, but I wanted to know what other people on the committee thought. Jason Burke pointed out that our scope increased quite a bit: we were originally tasked to come up with some formatting and maybe minor content changes that would make our content work better online. We ended up pitching topic templates, a structural overhaul, custom documentation, and Flare Feedback server to clients and management. Plus trainings and implementation guidance for the team. “There as a real focus on doing it right,” he also said.

None of these were things any of us had much prior knowledge of. There was a ton of research and trial and error. Everyone went down their own pet research rabbit holes at one time or another, which took time. Our manager admitted that she wondered at times whether she should have placed a deadline on more things in the project; she wonders how that would have changed our outcome. We used consensus rather than having a decision maker, and we were very thorough, she pointed out. Those things take time, and their products are different than a process where the group leader sets hard deadlines and makes the final call on ideas.

I have plans for a series of posts about this project, but for now I’ll just list the skills I improved during the course of it, with the goal of linking back to this list as I write the posts:

• Project management for group projects (how to keep all the notes)
• Influencing without authority (50 ways to not end a meeting)
• Fostering collaboration (how to kill your darlings)
• Collaborating with SharePoint sites (if you really must)
• Developing topic templates sans DITA (because it’s easier than asking for CMS)
• Internal selling/getting buy in (the clients want what?)
• Scheduling with clients (is far easier than scheduling with senior management)
• Demo scripts for multiple presenters (so people don’t hate their lines)
• Developing surveys (how to beat around the bush)
• How committees can keep larger teams happy (!)

I’m looking forward to these posts. It was worth examining what took so long, partly because in the process I was reminded of how well the HD group works together, now. There is more trust, we build on each other’s ideas, and we’re more efficient at producing those ideas. That experience of being on a strong team will serve us after the topic templates are long obsolete.