I conducted some context-sensitive online help usability testing with four users of a Web application. This post discusses the results (without getting overly academic in tone, I hope).

Objective

I wanted to find out whether and how quickly participants could find given pieces of information and answers to specific questions in two versions of a help system described in this post.

Specifically, context-sensitive topics in the first version have a screenshot giving an example of how the screen can be used, sometimes with numbers corresponding to annotations in the text below. The newer versions of extensive help topics had the screenshot hidden in a dropdown hotspot and details contained in dropdown hotspots instead of being annotated. Specifically, the hotspots were formatted as green, underlined text with a right double angle bracket afterward.

› Continue reading…

Documentation doesn’t need a full-blown usability test, lab with one-way mirror and all, but it should have something. That’s one thing I’ve been working on this week with a particular help system I described in my last post.

When doing usability testing on documentation, keep the following things in mind. (These apply to any type of usability testing, actually.)

1. The participant isn’t being tested—the documentation is. Make this clear to the participant. You may even want to put it as simply as, “You’re not being tested. I am.” You want to observe how a person interacts with the content. The participant will face no adverse consequences for not successfully completing a task.
2. Come up with scenarios and tasks where the context makes sense to the users. Similar to examples used in documentation, if the situations you present don’t make sense in the participant’s world, she’ll spend time getting confused or correcting you. Think through the context of the tasks you’re using to be sure it holds up.
3. The participant should speak out loud so you can record thoughts, feelings, and reactions. It’s okay in informal testing to ask, “What are you thinking right now?” or “Why did you choose that option?”
4. Any pause in movement of more than a couple of seconds means the user has to ponder what to do. That suggests a potential usability problem.
5. Put together follow-up questions to find out how the participant feels after interacting with the documentation. Of course, you’re looking for objective data and observations; however, one of the important things to find out is the impressions the participant comes away with regarding the documentation and the product. Those impressions could very well affect how much the person wants to have anything to do with your organization and its products.
6. It’s okay for the participant to give up. People do that. Explain this to the participant. Usability testing is about seeing whether people can complete tasks successfully most of the time (or ideally, all of the time). You may wonder whether telling the user that she can give up is somehow planting that idea in her mind. But if the person were on her own and trying to use the documentation, she would think of giving up just as quickly.

In one application I work on, I recently added some text to the context-sensitive help topic for a screen that allows financial secretaries to make a payment. The text described what to do with a particular control that had been added to the screen.

Because of the many variables involved in making a payment in various countries around the world, this screen has become functionally dense, leading to a help topic that I finally decided had become cumbersome. The bulk of it was a procedure for filling out the information, but in between steps was a lot of “if you need to do X, enter Y” and such things. Some of those extra explanations were only a couple of extra sentences, but added together, it was a lot of content being spewed at the user.

This is a Web application, so we don’t have field-level help. The growth of this help topic led me to imagine that if a user clicked Help for information about one particular field and had to slog through the text in that topic, they wouldn’t get very far before giving up. That much information punching you in the face would be enough discouragement without even beginning to scan it.

I needed a different approach.

› Continue reading…

The prevalence of search engines hasn’t pushed out indexing yet. I’m not an avid fan of indexing because of the time involved in putting one together, but a search capability is not always what users will employ to find information.

Search functions are generally included in help systems and is built in to Adobe Reader, so usually, users will not neglect the search with the excuse that there isn’t one. Like other conventions from when the only documentation was a manual, however, indexes continue to be a standard component, and I’m sure some people use them out of habit. But in cases where you provide a PDF and users print it, there’s no search, and it’s up to the table of contents and the index to tell them where to find what they’re looking for.

› Continue reading…

In one of my help projects, I put together styles for the topic titles and headings that visually divides the sections of the topics. Size and font weight aren’t the only things available for making headings stand out and the structure of a help topic understandable for the user. Here’s the styling I used, as well as another style that may help headings visually noticeable.

› Continue reading…

I’m starting a new help project, and I decided to take the opportunity to try something a little bit different. The help is going to be context-sensitive, probably WebHelp. In previous CSH projects, I provided an image of the screen and placed numbers in places where I was going to describe the functionality. Below the screenshot were corresponding annotations.

I have usually kept the how-to content separate. In one project, a separate manual described procedures for the various roles in the system. In another, I included how-to information in a second section in the table of contents. This time, I’m going to do something in between.

› Continue reading…

This post continues my comments on the results of my experiments using RoboHelp Packager for AIR on a WebHelp project.

General Bugs

Having Back and Forward buttons is great. However, in Classic Help, they didn’t always seem to follow my navigation path. I don’t use browse sequences (and I turned that feature off anyway in the AIR generation dialog), so I don’t think I’m misunderstanding the purpose of the buttons.

The Classic Help TOC seems a little buggy when the Favorites pane is open. Everything worked except when I had a bunch of books open and had to scroll to get to the last book. When I scrolled, I got behavior like the selected book or another book automatically closing, or the TOC would jump so I couldn’t see where the selected topic was. (If I scrolled back up, the auto-closing book would open up again.)

Where I had Captivate demos in a topic, a huge space was inserted before each Captivate demo about the size of the demo itself. The demos work fine, but that big space is an irritant.

› Continue reading…