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.

Testing Documentation on Co-workers: Part Two

You can find the first part of this post at Ben Minson’s blog, Gryphon Mountain Journals.

In the first part of this post, I talked about how our biggest challenge in adopting Steve Krug’s method of do-it-yourself usability testing was that our team was testing the documentation on co-workers. There were some other challenges, too.

Incredibly Specific Scenarios

People with a wide range of job titles use our software. They work in the same facility, but their domain knowledge, education level, influence, and familiarity with the system differ wildly. Wide variations between facilities can determine what types of job titles and tasks that our users have,too. I created a draft table of user roles, at one point, and I was looking at nine potential personas.

This meant that our time was limited for exploring scenarios specific to each user type. We had three users for 20-30 minutes each once a month. If the scenarios were not well-vetted and specific, who knows who our proxy users were pretending to be when we tested them?

At times, testers said things that made me realize that they were approaching the testing tasks not as if they were a customer, but an internal employee using the documentation. Sloppy scenarios could mean incorrect conclusions. As I improved scenarios, I started adding instructions like, “Pretend you are a system administrator in hospital laboratory.” I did this for each scenario to prevent testers from slipping “out of character.”

If I were continuing this project, my next step would be to identify the most critical types/personas and focus on scenarios pertinent to those. I hadn’t gotten that systematic, yet, but to a certain extent, I did use some educated guesses to focus on important users.

As I discovered the complexities of writing scenarios that didn’t flop, often what we used on test day was what I had discovered the most about during the course of preparing for the session, rather than scenarios that focused on the most important things to test in the content.

Recommendations, Meet Lunch Hour

I mentioned that we had about an hour and a half for testing each month. After the testing session, we had an hour for discussion over lunch, which Krug refers to as the debriefing. Our schedule was a modification of Krug’s recommendation, which is an hour per participant. As it was, people found it difficult to commit to 2 1/2 hours, and many skipped the noontime debriefing, even though we had the option to take a late lunch afterward.

The approach that my manager preferred was to make the testing sessions optional, but to have the outcomes of the discussions be binding. I thought this fit well with the idea of letting the benefits speak for themselves. It also meant that people we needed for some discussions were not present, putting a slight crimp in creating action items. That can be an issue in many meetings, though.

A Fuzzy To-do List

Ah, the outcomes of the debriefing, the post-testing discussion. Krug’s process is to go around the room and ask each observer to name the most severe issues he or she observed. From that list, then the group chooses the most severe issues and discussed solutions right then. The focus is on solutions that can be implemented that month.

This worked for us the first time, sort of. In our world, a month is a short, short time. It was hard to list anything that could definitely be done within the month, except for things like, “Add it to the department meeting agenda,” and, “Contact Jim to get more information.”

So, a good proportion of our next steps involved getting more information or prioritizing the issue on the to-do list where it already lived. The testing served as future ammunition, which was important, but not very exciting.

Testing the Content vs. Testing the Application

In our first testing session, we tested the application that our co-workers use to enter release notes, as well as the help system for that application. The next session tested our new help format and navigation. But for the most part, our sessions were to focus on testing the content of the help systems—do the instructions work?

So, when we set about testing the content of our release notes, I didn’t think there was need to give much a heads up to the writer on our team who helps develop that application. We were strictly looking at release notes written by various members of the team.

Except, people still got bogged down in the application. My scenarios started them too early in the process, where they had to use the application to find the notes. I thought I would pick up some peripheral information that way, but that’s where people got stuck giving feedback.

I think it’s easy to get distracted by giving feedback on a tangible window in an application, especially for our co-workers who help develop software. To test the content, I would need to skip the part where they have to deal with the interface, and just have them use the instructions I’m testing to perform tasks in the system.

Unexpected Benefits: Communication, Audience Analysis, Bartering

I’ve mentioned that we didn’t always get kick-ass to-do lists out of our testing sessions. We did get support for our ongoing improvements that we were trying to get sponsored, and we also got something else: communication with other teams.

We invited product people to watch the release note testing, and that gave us an opportunity to ask them more questions about our audience. It gave us a chance to demonstrate why sometimes we make the requests we make for them to improve the notes they write.

While writing the scenarios, I had to ask many people from other departments to vet them. “Would a customer do this? Would they know that?” I picked up quite bit of peripheral information about our audience that way.

Finally, the testing can be a way to offer benefits to other teams. Do you want upgraded software for the knowledge base? Let us test it so you can take metrics to upper management. Do you need to train a couple of your employees on the release note application? Have them come and watch how people use it. It’s one more way for the technical communications department to add value.

Two Weeks Notice > One Year OJT

Some of you already know that I gave notice at work and I’m moving to Chicago this week. I actually gave conditional notice a couple of months ago. Among other things, I asked to work on different projects.

The roles for technical communicators are pretty set at our company, but other departments do change and restructure quite a bit. I wanted to work on internal and external audience research and content strategy. It was a long shot, but not inconceivable.

My manager asked me, in several different one-on-one meetings, about what I wanted to work on. She took notes, and took those notes to her managers, but nobody ever said anything more about it, beyond my manager apologizing for the delay, and eventually it became clear that my long shot was out of range.

The Gauntlet is Not Just an E-Book

My manager explained that if I were to stay, one of my main focuses would be on mentoring.

What I heard was that I would work on .chms and WebHelps in a Tech Comm department silo until it was too late to break free into the next tax bracket.

This, of course, was an overreaction. But to call the mentoring role a cul-de-sac probably wasn’t an exaggeration, and that was hard to face. It was a skill set I wanted, but it wasn’t the time or the place.

I was intrigued, though, by her insistence on the team’s autonomy, and by my reaction to it. Consequently, it seemed everything I read or heard in the following weeks was related.

I had already seen this RSA white-board animation, actually, of a talk by Dan Pink, in which he says what people want most is autonomy. Okay, but how does that translate into a successful team?

I heard a bit on NPR about Frank Oppenheimer’s hands-off running of the Exploratorium in San Francisco, and the brilliant research that was produced in that environment. I’m having a hard time finding that July 13 story on NPR, but here’s an interview with his biographer. Anyway, I thought, “Well, but maybe you have to have people with the right experience and talent.”

In a nutshell, I picked at my blind spot. I could tell that I had an irrational resistance to something that I was fundamentally misunderstanding. Then I heard a podcast that, when it reminded me of work, made me wonder if I might be pushing the healthy limits of thinking on a work problem. I’ll share it with you anyway.

A Great Department Takes Time, and Manuals Aren’t Babies

One of my favorite radio shows is “This American Life” on Chicago Public Radio. Four months after the 2009 earthquake in Haiti, they did a show about the lagging relief efforts there.

The show outlines the obstacles in a program for helping mango farmers, a history of failed aid efforts in Haiti, and the contrast between a long-running missionary hospital and the Haitian-run clinic to which a doctor from the missionary hospital has transferred.

The doctor could be much more effective, in the short term, at the missionary hospital. The site was equipped for many more procedures than the Haitian-run clinic, and the American staff were trained to run in an efficient manner that was not the case at the Haitian-run clinic.

The trade off was the level of control and paternalism. Until recently, the wife of one of the founding doctors had worn the key to the medicine closet around her neck. One night when she was ill, they’d had to carry her out of her bed to unlock it for an emergency surgery.

The doctor ran the American clinic. At the Haitian clinic, he was one doctor among many. He was not in charge of anything. He had to watch people with injuries–including babies–that were relatively simple to treat suffer inefficient care, travel great distances from facility to facility to get their needs met, and sometimes die as a result.

It was frustrating, but perhaps less so than having the Haitian people resent the help they were receiving. The doctor was rejecting the “benevolent dictatorship” of the missionary hospital, which he saw as a failed model.

“The choice to then go the other extreme; to purposely work hard at not becoming a dictator for the sake of building community means that people are going to suffer, people are going to die. Goods will not be provided; services will not be rendered.”

In our case, no one is likely to die. Deadlines may not be met. Clients may not be impressed. They might be so unimpressed that they never press F1 again. Maybe those things will happen, and if we’re not measuring, we’ll never even know.

It’s a risk I’ll train myself to take.