I recently held some informal usability testing for some changes to an online help system I was considering. Because I hadn’t done any testing on the original help, I incorporated some of that as well. Doing so pretty much confirmed that I was on the right track with the changes I wanted to make. The help as it stood wasn’t very usable.

All documentation can stand some usability testing. We technical communicators like to claim that we’re user focused and user advocates. I like to believe that myself. However, sometimes we can be more like developers than we want to admit. We do things our way, the way we think is best. We may have even proved in the past that what we’re doing is pretty user-friendly. But times—and users—change.

› Continue reading…

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…

Last week, IT groups in the organization held a conference so that we could share techniques and best practices while saving the money it would take to send hundreds of people to external conferences. Because of the different roles represented aside from developers and testers, I had enough topics other than things like Java and test automation to keep me busy throughout the two days.

One of the sessions I attended was the basics of usability presented by a usability specialist and an interaction designer. The session included an exercise that illustrated why usability testing is important and how it can be done early in the process with little expense. The presenters divided the attendees into several groups, and each person received a role as product manager (or customer), user, program manager, business analyst, or interaction designer. Each had certain goals to meet with the product, and then we had to create prototypes consisting of sheets of paper and sticky notes written on with markers. At the end of the designated time, the user had to come in and try to accomplish certain tasks using the prototypes and navigating them with his finger.

I was the product manager for the group I was in, and I had some knowledge of the subject matter that the application related to, but sometimes the business analyst, program manager, and designer would ask me questions I didn’t have the answer to. Still, it was a fun exercise. And one of the points was that usability should be owned and encouraged by everyone on the team. We also found that at times, we overlooked very obvious things that were necessary in the interface.

› Continue reading…

Recently I conducted some usability testing on my procedures manual with a couple of users. As a result, I determined some specific items that I needed to change in the material. I also observed a few general principles applicable to future projects.

› Continue reading…

The idea of not trying to guess what users are looking for in documentation has been bumping around in my head since the STC Conference. I was talking to my manager yesterday about altering my approach to help. So far, what I have done (at least in context-sensitive help situations) has been to think about the details of application screens—how to use the controls, where prepopulated data come from, what happens downstream, how to get displayed data changed—and provide information in those areas.

I don’t think this cuts it anymore. Why? It’s the crystal ball approach.

› Continue reading…