Adding Usability Methods into Your Technical Communications

By Alice Preston

Are you confident in your technical communications skills? Or are you new to writing this type of materials for a living? In either case, your work and its usefulness can improve greatly if you add some Usability methods and practices into your work.

Today I’d like to talk about three kinds of research you can add into your process:
•Audience analysis: Know Thy User
•Task scenarios: Know How Your Materials Are Used
•Lightweight usability testing: Test the Tasks

Know Thy User

When I began as a Usability Engineer (the accepted title back in 1998), I received a lapel button from my new manager. It says “Know Thy User – For You are Not Your User.” This motto is ignored far more often than it is followed in technical circles, but it is central to the success of Usability and User Experience practices; and to the success of just about any product.

Around this come some other topics in user definition: Who are the users for your communications materials? What kind of environment do they work in? Do they know HEPA from HIPAA from EULA, or do you need to be sure to tone down the acronyms if you want them to succeed?

In whatever way you can gather such information, do it. Often technical communicators are unable to meet users directly, but you may have access to someone who works on the hotline or teaches classes (if either of those methods is used for your products). Or you might know that you’re working on a consumer product or that UNIX system administrators will be reading your materials. In those cases, do a little research to see whether your population appears in the UX literature, then carefully read the papers or articles that talk about what they do and when they succeed.

You may have read about Personas, and the material you gather can be helpful to get an idea of how you would start to construct those team artifacts. Be aware, however, that it’s a dangerous thing to construct Personas only from secondary data. I recommend getting as much information as you can using the above sources first, and then work on getting to where your users are so you can see the fine detail.

Sometimes, a company thinks that usage differences are all tied to job titles, and that the job titles tell you enough about your users to take the place of careful Persona research. But the UX community has many stories about projects where that wasn’t the right way to think of the data. Perhaps physical capabilities, hours spent playing a particular kind of video game, or industry knowledge are more important than whether a person is a manager or a producer.

Know How Your Materials Are Used

When users come to your communications product, what do they need it to help them do?

Think about your own use of your communications software. Is your job more about creating a deliverable or about using the software? Probably the former, and that’s true for your users as well. Whatever you are writing about, for your users, the subtasks that need to be performed are only steps on the way to accomplishing the “real” goal.

Therefore, when you are planning how to present your materials, align the presentation with your users’ goals, and present the materials that way. For example, when making a purchase, users may need information about what payment types are supported and how to enter that data. But that’s not the place to include a section about how to use Search.

As much as possible, try to write your materials from the “outside in” and not from the “inside out.” This will quite possibly not match the order in which your technical experts will give you the information. Many times, I was given information about “how to use the XYZ menu” when what the user wanted to know might have been “how do I compare the costs of ZZZ and YYY?” or “where is the file saved and how can I get it back after a problem?”

Test the Tasks

This may be the first mention in this article of a Usability Method that you recognize. However, if you’ve laid your groundwork well by following the first two practices, you are likely to be in a good place even if you are unable to do any formal testing.

I’m suggesting that if you have documented tasks in your materials, that you recruit someone else (several people, if you can) to go through them and verify their accuracy. Sit next to each person as they read and follow, and take careful notes of what they find. Let them struggle a bit if necessary, to see what suggestions they come up with. And don’t be hurt if it turns out that your user definitions or your task scenarios need some tuning. They often do, especially when your research has been done within secondary sources.

Who do you recruit? This may depend on what kinds of users you think you need, and whether there are people of that type within your company or your circle of acquaintances and family. Get as close to your expected users as you can, and understand that the farther you are, the more you may need to ask careful questions about your findings.

Repeat

These usability methods can be applied to almost any kind of project or deliverable, they never become old, and there is always something more to learn. As you start using them on communications projects, I predict you will become ever more fascinated by people, where they come from, what they know or don’t know, what they can do or cannot do, and the types of assistance they need from us. What a wonderful profession!

If you want to know more about Usability methods and how to use them with Technical Communications, there are excellent sources of materials online, including the past issues of the newsletter for the STC’s Usability and User Experience Special Interest Group.

About the author:

Alice Preston came to User Experience after a 20-year career as a technical communicator in database and telecommunications software. She has held the UX role in telecomm, non-profit, business analysis for legal, educational, and now advertising software companies. After this 360-degree examination of both roles, she observes that people are much the same everywhere.