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.

My opinion of why managers generally resist or overlook usability testing is that it can be seen as churn. The manager may say, “We already designed, developed, and tested that functionality according to the customer’s specs [or user stories, use cases, or whatever you happen to call them]. If we do usability testing, we’re just rehashing the same steps, covering the same ground, instead of moving on to new development.” The presenters suggested that people may also hesitate because they believe the myth that usability testing has to be a big production with expensive labs.

One of my colleagues from the User Education team works with the presenters, and as the usability specialist spoke, she talked about how she would keep him informed of the results of the usability tests. She admitted that not every problem discovered in the testing can be resolved by the development team, so that’s when she called on the writer to lessen the problems by providing good documentation.

I was thinking about the topic recently of where usability and documentation meet, so this session caused me to think about it further. It’s kind of a funny concept because I would say documentation is part of usability, but when we’re talking about the usability of a product itself, the documentation has to meet it somewhere. The project team can do only so much given aggressive schedules and limited money to perfect everything. So the documentation picks up the slack, so to speak.

This is not to say that documentation is a product crutch. An interaction designer I know who used to be a usability specialist once gave me a pin-on button that says, “No, you can’t just explain it in the manual.” That is, the product has to have its own merit and not rely on the documentation to explain the user’s way through all the problems. That’s probably something to keep in mind when we encounter usability problems in the products we work with; rather than just document it, we should speak up. We stand with one foot on each side of the line between user and project team, so we can give advance warning of usability problems.

As technical writers, we have an inherent interest in usability. We approach a product thinking like the user, considering how the user will use it, so we easily catch usability problems. And the less usable the product is, the harder we have to work to explain it and how to use it.

At the risk of repeating myself, I’ve mentioned here before that I dislike hearing someone say that if the product is designed well or is intuitive, then it doesn’t need documentation. I’ve got news for subscribers to this philosophy: “Intuitive” is a subjective term, and it can be persuasively argued that nothing is really intuitive because we have to learn pretty much everything from the time we’re born. My point is that usability goes only so far before documentation has to step in anyway.

What can you do when it comes to usability testing?

  • First, speak up. Give your voice in support of it. Talk about the merits. If you first need to learn about the benefits of usability testing, research it so you can speak with confidence.
  • Second, get involved in the testing. Offer to assist whoever takes the lead. If this is you, then you’ll obviously be involved, but if there’s a usability specialist or designer in charge, explain why you have an interest in the results of the testing. I’m sure they’d be happy to have help.
  • Third, understand what the team won’t be able to change and decide whether you need to fill in the gap.

One designer I work with has been trying to arrange some informal usability testing on a set of features, but things have been getting in the way. But I’m excited that he’s trying to do it and that he’s willing to have me there to observe. The project can only benefit, even with looming deadlines and limited funds. And the documentation can only benefit, too.

Related entries (auto-generated):

Six Things to Remember in Your Documentation Usability Testing

Why a Transition from Tech Comm to Usability Makes Sense

Some Observations from Documentation Usability Testing

Documentation Needs Usability Testing, Too

Technical Communication: The QA of Product Design