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…

Bookmark It

Hide Sites

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.

Bookmark It

Hide Sites

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…

Bookmark It

Hide Sites

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…

Bookmark It

Hide Sites

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…

Bookmark It

Hide Sites

Yesterday I met with the interaction designer (I’ll call him Joe) on a certain project so that we could discuss text on a few screens he had designed. “I’m not a writer,” he said, “so I have a hard time getting things just right.” To help him phrase the text, I had to understand the screens, so he spent some time explaining the concepts. This was mutually beneficial, since I’ll soon be writing the documentation for those screens.

I mentioned to him that a designer had said that if an application is designed well, it doesn’t need help. Joe smiled and said that it’s what they (meaning the design team or designers in general, I think) refer to as a “sexy thought”—it sounds nice in theory but really isn’t true.

› Continue reading…

Bookmark It

Hide Sites

This post is part of a series on usability and maintainability. At first, meeting the needs of content consumers through usability can seem at odds with meeting needs of technical communicators through maintainability. My purpose in these posts is to discuss how technical communication best practices can satisfy both needs. I’ll use Gurak and Lannon’s usability criteria of users being able to “find what they need, understand the language, follow the instructions, and read the graphics” (A Concise Guide to Technical Communication, 31).

What about instructions can stop people from following them? This is a question about the structure of the instructions themselves, separate from the language you use, which was the previous subject in this series.

Structure of Instructions

The main obstacle I’ve heard when asking this is when instructions are too long and complicated. I’m sure we’ve all seen—and perhaps even written at some point—steps in a process that ended up turning into fat paragraphs. Or a set of instructions has twenty or thirty steps.

The rule I was taught in college was not to exceed six lines in any paragraph. I admit that I have broken that rule because I have written material where it didn’t make sense to me to break the paragraph at six lines. However, the theory behind the rule is that people get lost in dense text and also lose a sense of progression. (Charles Dickens would not have made it as a technical writer.)

› Continue reading…

Bookmark It

Hide Sites

This post is part of a series on usability and maintainability. At first, meeting the needs of content consumers through usability can seem at odds with meeting needs of technical communicators through maintainability. My purpose in these posts is to discuss how technical communication best practices can satisfy both needs. I’ll use Gurak and Lannon’s usability criteria of users being able to “find what they need, understand the language, follow the instructions, and read the graphics” (A Concise Guide to Technical Communication, 31).

Simple Writing

A style of consistent, concise, simple writing benefits both users and technical authors. In the United States, the average adult reading level is judged to be 8th to 9th grade (ages 13 to 15), and I think it’s safe to assume that readers at higher levels comprehend writing at that average level or lower. (That statistic is cited as coming from the National Center for Education Statistics in a 2002 study, but that source is only referred to and not published online as far as I can tell.)

› Continue reading…

Bookmark It

Hide Sites

This post is part of a series on usability and maintainability. At first, meeting the needs of content consumers through usability can seem at odds with meeting needs of technical communicators through maintainability. My purpose in these posts is to discuss how technical communication best practices can satisfy both needs. I’ll use Gurak and Lannon’s usability criteria of users being able to “find what they need, understand the language, follow the instructions, and read the graphics” (A Concise Guide to Technical Communication, 31).

Effective Searching

Text searching has become a prominent, if not the primary, method of locating information electronically, thanks to Google and other search engines. I fall into the search camp; I may glance through a table of contents, but if I don’t quickly locate what I want that way, I turn to searching. Documentation authoring software typically provides a search mechanism for users out of the box, so this provides a bonus for technical communicators through needing little or no maintenance. I mention it here mostly because these days, when people think of finding something electronically, they think search.

Thorough Indexing

Indexing is a leftover from the days when all documentation was delivered in print and that text searching was not available. Some users rely on indexing probably out of habit. But one advantage of indexing is that it acts as a backup in case a search proves ineffective (such as when the same word has a specific meaning as well as a generic meaning in the content—in this case, the search will pick up every instance, while the index will point only to the relevant instances.

› Continue reading…

Bookmark It

Hide Sites

A few days ago, I posted some thoughts I was having about usability and maintainability. On the surface, they seemed to be two ideas that couldn’t exist together. As I’ve thought further on it, I’ve decided that there may be situations (such as an example I gave in the first post) where this is the case. But on the other hand, the two can go together quite comfortably.

I refreshed my memory on what constitutes usability by cracking open Gurak and Lannon’s A Concise Guide to Technical Communication, a book on tech writing basics that I used in college. (It’s good to return to the basics every once in a while.) Speaking of a technical communication product, they say that people will “use it only if they can find what they need, understand the language, follow the instructions, and read the graphics” (p. 31). Based on these criteria, I’m putting together a series that looks at the places that usability and maintainability not only meet, but also sit down and have a nice dinner together.

On a basic level, simplicity is the key. Users catch on to simple, you can maintain simple, and those who come after you to maintain your work can figure out simple.

We should design and write primarily with our users in mind, but if you work where usability and maintainability overlap, it’s okay to be a little selfish and write with ourselves as considerations, too. If you can create content that benefits both users and yourself, you’re that much closer to making everyone happy, and you’re adding value all around.

Previous: Usability vs. Maintainability in Technical Documentation

Next: Usability and Maintainability: Navigable Information

Bookmark It

Hide Sites