Many times when I think of surveys, I think of the Animaniacs cartoon with the ladies who asked the three Warner siblings, “Would you like to take a survey?” There followed many questions with every imaginable permutation based around George Wendt, movies, and bean-eating.

Recently I conducted an online survey on the training and help materials for System X, a Web-based app for office staff. I didn’t ask a single question about George Wendt or beans. My two main goals were:

1. Find out how good the training was that the respondents received in person
2. Learn how much the respondents use the training and help materials in the application and how effective the materials are

Basic Results

I ended up with sixteen questions, some of which were demographic. According to Qualtrics (the software I used), 497 people accessed the survey, and 420 people completed it. However, I found as I analyzed the results that some respondents skipped questions and didn’t really fill it out completely. Still, about 230 out of 340 worldwide offices were represented in the result set, and I’m happy with the relatively high response rate.

As a bit of background, we have an online help system and a training page for this app. The training page has links to role-based quick reference guides in PDF and video demos in Flash. The help is your typical old-school tripane WebHelp with index, search, and so on.

Here are some key findings (numbers taken from those who responded, not the overall 497 or 420):

• 42.7% were not aware of the quick reference guides
• 28.3% were aware of QRGs but never use them
• About 25% have used QRGs at least once
• Average effectiveness rating out of 1 to 7 is 4.11 (so just above moderate)
• About 85% print QRGs when they use them

› Continue reading…

Bookmark It

Hide Sites

Sometimes I get ideas about a problem I’m trying to solve once I’ve stopped actively thinking about it and have let it drift into the back of my mind. With Project Pinnacle, something escaped my attention until a few weeks after my visit to the pilot site.

Well, it didn’t entirely escape my notice, but its implications for documentation and training didn’t hit me immediately.

The thing I noticed while watching users try out my quick reference guides was that they tended to follow only the first few steps of the procedure. They would look at it long enough to get to the screen where they performed the task, and then they would try to do the rest without the guides.

One of the reasons for this is that they had to keep glancing between the monitor and the paper, which made it easy to lose their place. Trying to use a finger didn’t help much either because at some point they had to start typing.

A few weeks after my visit, I got an idea of maybe a true quick reference guide that would fit what they needed. Since they relied on the printed procedures only for navigation, why not just provide the navigation steps?

I put together a version of each guide that listed the steps with double angle brackets between each step. This condensed the existing material from about four pages for each guide down to under one page. I haven’t tried these versions out yet. The project manager wasn’t in favor of the version of the guides that have the screenshots with callouts because of the cost of keeping the screenshots current for all languages.

When I first reported to the project leadership about my visit to the pilot site, I pointed out that a way to improve our training of our audience and at the same time reduce documentation costs would be to provide more prompts in the application. I’m not trying to reduce my workload, but I believe that the more help you provide in the interface, the less help you have to maintain elsewhere. I know, not real profound, but it’s not something very many product designers think about.

Since then, I’ve provided prompts and descriptions for a number of application screens and features. We’ve seen a direct impact of this as we’ve worked on the training video scripts. We want to keep the verbal explanations simple and let the features be demonstrated so that we don’t have to rerecord the audio if features change. The fact that we’re including help in the interface helps us do this because we can leave much of the explanation to the application itself.

Image credit: Salvatore Vuono, freedigitalphotos.net

Bookmark It

Hide Sites

Last week I visited the pilot location for Project Pinnacle. My focus was to see how well my first-draft quick reference guides worked, but I spent some time training.

The office staff tended to want to ask me how to do things and be walked through it, but I took those times to ask them to test out the instructions for me. However, on one occasion, I had to guide a brand-new user through a somewhat complicated scheduling procedure while she was on the phone with the person setting up the appointment. I figured it would be better to help her through that one because she’d feel enough pressure from trying to do it right and in a timely manner.

In addition to notes on improvements to make to the guides, I kept other notes. The rundown:

• 5 tasks to add to the guides
• 14 other changes needed to the guides
• 20 feature or change requests
• 10 bugs
• 14 miscellaneous items that were questions, observations, or usability problems

› Continue reading…

Bookmark It

Hide Sites

In our quest to get more decision-making weight in the organization, the User Education team is putting together a set of standard practices. You may wonder why we don’t already have these. To put it succinctly, we still have to carve out our place in the IT department’s project lifecycle so that at least most projects have a user education component to them. Since there have been only a few of us, we’ve operated mostly by our own judgment, each person doing what he judged appropriate for each project.

We’ve come to realize that if we want our department to take us seriously and give us the place we want, we need to be equipped to justify the decisions we make on what user education products are right for any given project. One of the things I’d like to see happen in our team is to develop a menu of products, each with a specific definition and an explanation of the situation(s) in which we would recommend that product.

I’ve taken a first shot at this. I’d like your help to flesh this list out, the descriptions, and the reasons you’d use each one. In the comments, please let me know what I’ve left out.

Quick Reference Guide: One-to-eight-page guide that contains reference information, repeatable tasks, or some combination of these. Used when users have small number of tasks or will frequently need to refer to charts, tabular data, and so on.

Quick-Start Guide: One or two sheets that explain the steps for setting something up. Could also provide a set of most common tasks. A throw-away document. Focus may lean toward one-time training.

Short Guide: Thirty-to-forty-page document that provides task steps and reference information. Used when there is too much information for a quick reference guide.

› Continue reading…

Bookmark It

Hide Sites

This month we’re transitioning from an old custom document generation application to a new one. Having been the person responsible for training a small group of users, I spent much of yesterday with the person upon whom falls many of the weekly tasks. The project team and our customers wanted to be sure that she’s ready to go when we’re live with the new application and the old one is turned off. (The old one is connected to a legacy database that will be retired soon, so it won’t be available as a backup for very long.)

As we went through the document generation process, this particular user—let’s call her Melissa—let me know where she wasn’t clear on one thing or another. Particularly, she wasn’t clear on what were the exact differences between each of the three screens that the process involves. As we got to the end and Melissa still seemed a little fuzzy, I asked, “Would it be helpful to have a one-page guide that walks through the three basic steps?”

Now, there is a help system. I even have a topic that covers this process from start to finish, involving about ten main steps. However, I could suddenly visualize a page where I matched three steps (with a few substeps each) with the three screens. But the approach here was to give the instructions in their most basic form and leave out a bunch of the details.

› Continue reading…

Bookmark It

Hide Sites

Yesterday, I gave an STC Web seminar on using quick reference guides as part of a documentation set. (I’ve included a picture of how I used my wife’s earwarmer to work around the fact that the speakerphone feature on my new phones is less than desirable.) I answered a number of questions that participants typed into the meeting’s chat box and would like to pass them on. However, I ran into some technical difficulty when I tried to save the chat transcript, so I’m going from memory when writing these questions. These aren’t in any particular order other than the order in which I remembered them. I’ll also do my best to answer, especially now that I’m not on the spot.

What’s your favorite typeface for quick reference guides?

Given the audiences I write for, I anticipate that most of my guides are going to be printed, so I use a serif typeface for body text. I’ve gotten somewhat weary of Times New Roman—so little personality to go along with its readability—so I’ve gone to Cambria. (I know that Word 2007 has heading styles pre-programmed using Cambria, but I usually use sans serif typefaces for headings.) I think Cambria makes a good body typeface.

For headings, I may use Arial, Lucida Sans Unicode, or something similar. I don’t really care for Verdana because it’s so wide. And when you bold Verdana text, it blows up like a balloon.

How do you estimate how long it takes to create a quick reference guide?

That’s a tough question because it varies. How long a guide will take depends on how much of the content is text or images, how much of the content you can use from an existing help system, and so on. If you’re just starting to create quick reference guides, they may take you longer, but as you do more, you’ll probably get faster at them. But each one can take its own tender loving care, so it’s hard to say for sure.

› Continue reading…

Bookmark It

Hide Sites

Kevin Cuddihy has posted my guest post on STC’s Notebook in advance of Wednesday’s Web seminar on quick reference guides.

As of this morning, 58 people are signed up, which is exciting and a bit intimidating at the same time.

If you’re interested, you can get more information and sign up on STC’s seminars page.

Bookmark It

Hide Sites

At the STC Summit, Tom Johnson and I gave a presentation entitled “Quick Reference Guides: Short and Sweet Technical Documentation.” Frankly, I was kind of proud of that title because it just fit within the eight-word limit.

Like usual when I’m speaking in public, I was nervous beforehand, my mouth went dry within the first few minutes, and after that I was fine.

Overall, comments were good. Someone went as far as to say that our presentation gave him the most specific information in the three years he’s attended the Summit. We had a full room, and three people watched from the hall. On the other hand, an anonymous (according to Tom) person tweeted that our presentation was more frustrating than interesting and lacked a moderator and concreteness. I’m not sure why the person chose to be anonymous; I hope it wasn’t a fear of some kind of backlash. Tom and I aren’t going to turn around and send hate-tweets.

It was a good experience, but after something like that, I feel like not presenting for the next five years. It’s a lot of buildup to that one hour, and then afterward I second-guess my performance. As Tom pointed out as we discussed it later, that piece of negative feedback did make us think about how to do better. If the world had no naysayers or detractors, maybe we’d have less motivation to improve things.

› Continue reading…

Bookmark It

Hide Sites

Because I work on a family of applications that are being developed to replace a legacy program, sometimes my work of documentation and training directly supports the transition from legacy to new. Part of the development team’s replacing and enhancing the legacy functionality is providing a series of reports on data in the systems.

One of my assignments is to provide some documentation that will tell the users how to use the new report prompts and parameters to obtain certain result sets that they have gotten with the legacy reports. My concern with this request is that it is essentially throw-away documentation. Other material I’ve created that relates to this transition period has been around for months and even years now. But we’re getting close enough to turning off the legacy system that I hesitated to produce documentation with a life of only a few months.

› Continue reading…

Bookmark It

Hide Sites