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.

Surveys: How to Beat Around the Bush

I didn’t expect tech writing to involve creating so many surveys. One day I may go back and get another degree in math or statistics and then just specialize in creating surveys and analyzing product users—I like making surveys that much. For now, my goal is to learn about Google’s survey tool and branch out from SurveyMonkey.

Several years ago, our department achieved a coup by getting permission to pass out a survey on documentation at our user conference. We stood outside the one of the conference halls as people waited in line to file in, chatting and handing out surveys. I enjoyed getting to talk to actual customers.

We got about 40 responses out of all the folks who took surveys—not bad. But, we had no follow-up plan for using the information. Management didn’t develop one and I was too inexperienced to effectively push for such a plan. We made a tweak to release notes as a result, but the effort is largely remembered (unfairly) as much to-do about a survey that didn’t pan out to results.

I would argue that we got a baseline of responses to common questions that we can ask repeatedly over time. Besides, what can you expect from one survey? One survey does not equal user analysis. It’s a baby step.

The following year some team members took another survey to the same conference, but the surveys sat in a stack on a table. Team members remember three people taking surveys; none were returned. It was the year of no surveys.

The next round of surveys came with the Help Design project. When we were ready to show a prototype of our new help system format, our director asked us to gather responses from the focus group in a written form, such as a survey. This would be easier for us to take those tangible preferences to other stakeholders within the company in order to get our ideas implemented.

Currently, I’m involved in two new surveys: one at work to gather general information about our users and one for the Usability and User Experience SIG of STC to gather requirements for their web site redesign. As a matter of fact, it would be helpful if took that survey, if you are interested in usability; here it is.

I’m starting to see some helpful patterns, which I’ll share here:

• List your objectives.
  Once you start sending your survey questions around to a group for review, it’s easier to talk about which questions should or shouldn’t be included if you can talk about which objectives the survey supports. You can brainstorm a list of overall objectives for user analysis, then choose which handful of objectives you are focusing on for this particular survey.
• Think about how often you will solicit input from users.
  When will you do your next survey or some other form of user input?We decided to do two outreaches per year, in addition to ongoing help system analytics. It’s easier to let go of some of the objectives for this round if you know you can focus on them next time.
• Cultivate a list of contacts.
  Our current survey will go to the clients who weren’t able to be included in the help design focus group. This is the result of a few courtesy emails on my part. We sent out an email soliciting clients for the focus group, but there was limited space. For the folks who weren’t included, I emailed to let them know we didn’t have space for them and asking if I could contact them for future feedback opportunities. Not one of them said no.
• Give concrete examples to make the questions easier.
  I tend to think of this as beating around the bush. If one of your objectives is find out what types of manuals and other deliverables you should be providing, I don’t think you should ask, “What types of manuals would be helpful to you?” That’s a question for tech writers—we’re the experts on that. The survey should gather related information that helps us answer that question. Here’s something a little better: “How do you like to learn new things?” followed by some examples, “A. Instructional videos. B. From a co-worker. C. Classroom training. D. Trial and error on my own.”
• Make the questions distinct from each other and keep it short.
  Please don’t make a survey that reminds people of a behavioral-style job interview. Do you take three questions out of ten to gather demographics? Unless user demographics is one of your major objectives, cut it down and combine questions. Are your questions distinct from each other, or will respondents get annoyed by thinking they have just answered the same question twice? You might be trying to discern a subtle difference with the two questions, but that might not be apparent to someone who is quickly completing the survey.

Building Fringe Benefits into a Project Plan

The Benefits of a Winding Path

In a previous post, I wrote about momentum problems with our team’s help system design project (a.k.a. HD). I am happy with the unexpected benefits and the unexpected learning opportunities that the project yielded, but the amount of time it took still seems inordinate. After posting, I got curious about ways to plan a project while leaving room for those types of fringe benefits.

Here are some of the benefits we got out of spending so much time with the project (and with each other):

• Team building skills
• Consensus building skills
• Client service skills
• Survey-writing skills
• Presentation skills
• Training skills
• Research skills
• Whatever other technical skills necessary to produce the deliverable (our deliverables were XHTML topic templates for each information type, plus methods to guide our team in converting tens of thousands of topics to a new format)

Stopping for Directions

It seems like it would be easier to plan ahead for gaining bonus skills and relationships by being honest about not having them in the first place.

Um, doesn’t that mean you won’t get to participate in the project?

It depends. Is the culture of your team that people are encouraged to take projects in order to grow skills? There’s more to it than cranking out documents to get deliveries out the door—it takes an investment of time to advance the team’s skills. Is it a critical deliverable for a critical client? Is there someone on the team who is already an expert who can take you under their wing? If there is an expert, but they don’t have mentoring skills, what then?

I can’t imagine my manager refusing to let someone participate in a project they were interested in without helping that person find another way to develop the interest. In addition, one criteria for getting promoted is to act as a leader and a mentor. There is incentive to grow these skills. There is opportunity to work on new things. I think these two things work together to make the team sustainable. I know this combination is one of the biggest factors in my having stayed on the team for four years.

Planning Ahead for Detours

After HD, I’ve established for myself that fringe benefits are usually worth the time they add to a project. This week I’ve been thinking of ways to draft a project plan at the outset that I can use to justify the skill development.

List the Expected Deliverables
This and the next item were inspired by GTD, which I read over six months into the HD project. List anything you will be expected to produce for the project, such as training, templates, presentations for each stakeholder group, status updates for the larger team. List them for your manager to make sure your expectations match hers.

This is a good time to candidly discuss with her if any of the deliverables make you nervous. “I’m not good on the phone,” or, “It usually takes Dave and I a while to come to agreement.” You can brainstorm with her how you will address the concern. Do you need to build extra discussion time into the project plan? Do you need to attend your company’s meeting training and agree on a meeting format for the project?

Add the concerns and the necessary time to the project plan. If you’ll have to research something in order make a decision, add time for that, too. If your manager balks at the extra resources, she can recommend another way to address the need.

You can always ask again in the midst of the project if it becomes apparent that you really do need the research or the discussion. I can think of so many meeting discussions that ran over the allotted agenda time when it would have been useful to be able to say, “Our project plan says we will have this decided by today. Do we need to add a week to the time line so that we can have this decided by next meeting?”

List the Criteria for Success
This is also GTD-inspired. We were almost finished after a long, rough ride on the HD project. We were ready to present to the team and start using the new format. Our manager asked us to present to her first. Then she proceeded to rip holes in our design. We spent another month getting the new templates up to snuff because they didn’t meet her criteria.

We should have clearly discussed criteria for each project deliverable ahead of time, and we did at that time. It was frustrating to be having a discussion we clearly should have had at the outset to make sure our criteria met the department needs.

I almost think you can’t be too detailed about doing this. Probably each deliverable should have criteria that you can refer to when you are deciding if the deliverable is good enough.

This Advice Fits in the Glove Compartment

Groan, I know. Sorry. I think what it boils down to is to be explicit at the beginning of a project about what the project parts are and where you will need to develop team knowledge in order to be successful. Then make that development part of the project. Add skill development as tasks and allocate time for it. You might not get everything you ask for, but at the very least you’ll be clear about which team skills you’re developing in this project and which ones you are postponing for another time.

How do You Make a Team Project Move Faster without Formal Authority?

No really, how do you?

Our team has had a committee working on help design (a.k.a. HD) for a year and a half.

Yesterday we unveiled the department desk reference topics for the new format. I fired up the projector, showed that the new book had been added to the TOC of the desk reference WebHelp file, and then outlined each part of the new content: concept and task topics about using the new topic templates, converting legacy topics, and structuring a TOC.

It took nine minutes.

We’ve already presented several times on the new format. Only two people have used it yet, one of whom helped design it. We don’t have trainings developed yet. I considered yesterday’s introduction a formality; a heads up that the desk reference has the info and a chance for the team to ask questions.

Our manager explained that she won’t really be pushing for people to implement the new format until we’ve had formal trainings, which the HD committee is charged with developing. Someone asked, “When will we have the trainings?”

“Um, well, we just started working on them, but the goal is to have them as soon as possible.” I am well aware that this is not actually an ETA, and I look to the other committee members for help. But by now I think they are pretty used to letting me talk in meetings, and they are apparently comfortable with letting this statement stand without amendment.

My manager tries a different angle. “Do you have a ballpark idea? Will it be a couple of months? A couple of weeks?” I know she is hoping I’ll say a couple of weeks, because it’s time for us to implement this format, already.

But until last week, the committee was completely focused on developing a great demo to sell clients and internal stakeholders on the new format, and before that milestone we were completely focused on finishing the design.

In order to get momentum on the trainings in last week’s meeting, I launched right into the “how” discussion and skipped over the “when” questions, which tend to stall us. And by now, I know better than to estimate an ETA for our group without discussing it with them first. They are apparently not up for discussing it right then in front of everyone. So I hem and haw a bit and then the meeting is over.

I’ve come to two conclusions as a result.

One, I’d like to pick dates for the trainings—aggressive ones—and work towards them. I think we’re at the point in the project where we should be able to do that.

The question is, how do I help the rest of the committee be confident in an aggressive date and willing to adopt that sense of urgency? So far, the only idea I have is to ask my manager to impose the dates. I can look at our training calendar and look at how soon we’re wanting to implement and see which dates we should choose. I can accept “good enough” over “perfect” in order to meet those dates. But, historically in HD, I can’t make the rest of the team see what I see on the calendar.

I think that, ideally, we would have had a project plan with a set amount of time for each milestone. We definitely took the meandering path, which let us reap some benefits that we wouldn’t have thought to include on a project plan. My guess is that this long finish is part of the price tag on that.

Two, I want someone else to take a turn at representing us to the team.

I’ve had plenty of practice and it’s time for someone else to work on that skill. I guess I’ve been hoarding it, in fact. The result was yesterday–crickets from both sides of the room. I just wish I would have thought of that before the end of the project. Any suggestions on passing the torch?

P.S. I am pretty excited about developing the trainings, actually.

It’s new for me, and I want to try out some ideas that my Twitter friend, Julio, recommends in this post.

Julio has instructional design background, and we’ve been chatting about tiered training. Tiered training! Twitter helped me find a way to squeeze that skill into my current job description. If you need more reasons to finally get on Twitter, read this post by Penelope Trunk.

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?