STC Usability SIG Newsletter
Usability Interface

What I Learned as a Writer from Doing Usability and Interface Testing

by Anne F. Jackson

Usability testing was an important success factor in a recent project on designing an online interactive help system. As a group of graduate students at Carnegie Mellon University, we had widely ranging backgrounds, but none of us had experience with usability testing or user observations. Involvement with our users provided a great deal of expected and unexpected feedback to the group, and helped us tremendously to learn more about our users, and ourselves as writers and information designers.

As a writer, I hadn’t had any experience with usability testing. When I recently returned to graduate school at Carnegie Mellon University, however, I worked with a team of other writers to create a prototype of an interactive online interactive help system. Part of our work included user interviews and observations, and usability testing for our prototype. Although this was a rich learning environment overall, our team felt strongly that we learned the most from our experiences working directly with our users. Maybe the reason is because we thought that we knew our users and what they wanted.

Watching users interact with both typical online help systems and with our prototype though, gave us an increased confidence that a user-centered approach to writing and design is the best way to ensure that our help systems are actually useful for our users as they try to solve problems.

How user interviews, observations, and testing influenced the prototype

We started with an idea for a help system that allows users to select how much information they see for a given topic. In our initial user interviews, we discovered how much users hated to use help because they didn’t feel that it gave them the answers that they needed: they would often go to any other possible source of assistance before using help.

A key influence, then, on the prototype was that regardless of the user’s experience level (novice, intermediate, advanced), users said that they just wanted the answer to their question. Such a simple thing—and especially because as writers, that should be obvious. But how easily we get distracted by the sheer amount of information on tasks that the user can perform with any given application! How do we know how much information is enough?

Our approach was to create a core set of step-by-step instructions for each task that was included in all three levels. We then built out from these common instructions, adding in background and more detailed technical discussions in the "More Information" and "Advanced" sections.

An interesting assumption that our users made on the first prototype was based on the labels that we used (Quick and Easy, More Information, Advanced). If the last level was "Advanced," then the other two levels must be cleverly disguised as "beginner" and "intermediate." As a result, we changed the second prototype to use the term "Configuration."

Another change was the interface itself. While the first prototype used a "dial" concept, we discovered that what seemed clear to us when we were designing the prototype was totally unclear to our users. As a result of the usability testing, we changed the second prototype to use color as a metaphor to indicate depth or complexity:

Figure 1 – Prototype one: Dial interface

Figure 2 - Prototype two: Color-coded boxes

Lessons Learned

Two things emerged from my experiences with our test subjects. The first, surprise that I should be surprised to learn what should have been completely obvious: when faced with a task, all users—regardless of experience—just wanted the answer to their question. Almost all users clicked on "Quick and Easy" as their first selection. Secondly, I was surprised at how emotionally users felt about online help. Users’ trust, frustration, and relief were part of almost all of my user interactions: the interviews, observations, and the prototype usability testing.

The most important learning experience for me was an increased respect, commitment, and confidence in usability testing. It was so rewarding to see that a different approach to information design can make life easier for users, and that the conclusion was based on evidence and first-hand experience, not just on "probably's" or intuition. What now seems obvious—that users need to find faster and easier ways to solve their problems—is still a difficult target for us. It’s a challenge to make time for testing with short market windows and aggressive development schedules. But I believe that, to the extent that we as writers involve our users more directly with our writing and information design efforts, our documents become the truly useful problem-solving tools that we hope for.