Journals by RSS
Journals by EmailA couple of weeks ago, I approached one of the project managers I work with about conducting usability testing on that project. This is an application that is used in hundreds of offices around the world, and we frequently receive enhancement requests via the feedback option provided in the software. It’s apparent that the users care about the usability of the product and about making it better. This manager suggested we bring up the subject with the interaction designer and business analyst.
We did so, and the interaction designer’s question was along the lines of “Why do you, a tech writer, want to do usability testing?” I could tell he was a bit confused.
Why would a technical communicator be interested in usability testing of the product, particularly in participating in the process?
Reason 1: It Makes My Job Easier
We tech writers care about the usability of products. The greater the degree of usability, the easier our jobs are. The less usable a product is, the harder we have to work to try holding up the weak parts with the documentation. And it doesn’t work. We don’t like frustrated users.
In his presentation at the STC Summit, usability specialist Scott Butler of OVO Studios said, “I’ve never seen documentation solve a usability problem.”
I think I hear some mental brakes squealing. What do you mean, documentation doesn’t solve usability problems?
If you don’t agree with this, I think you will after thinking about it a bit. To say that documentation should solve usability problems is to say that it’s a crutch that a product can lean on when it can’t stand on its own feet. I don’t say that documentation doesn’t make a product more usable, only that it doesn’t really make up for the fact that the project team should have taken the time to perform usability testing and didn’t.
Products with low usability are hard to explain and describe. You find yourself asking more questions than you should have to and writing procedures with too many steps. You spend more time trying to get your own head around the product.
On the other hand, a usable product lends itself to straightforward, simple user assistance. Remember, nothing except eating, sleeping, and breathing is truly intuitive to people, so most people need help some of the time. So usability testing doesn’t lead to the extinction of technical writing.
For example, a colleague of mine (I’ll call him Darren to protect the innocent) said this week that his father-in-law is eighty-two. When Darren’s mother-in-law saw Darren using his iPod Touch, she asked about it and ended up buying one for herself and another for her husband. The results countered the popular assertion that Apple’s i-products are easy to use and intuitive. Darren’s father-in-law needed instructions at least on how to properly move his fingers to operate the iPod Touch, if not more. But having a simplified product like an iPod would probably make creating user assistance easier than something more complex.
But I’ll grant that when the team conducts usability testing and makes changes based on only some of the findings, at least you’ll be able to address the rest of the problems by providing useful docs. So you may still have to smooth things over with your content and, you hope, improve the user experience as a result.
Reason 2: It Introduces Me to the Users
Being an organizer of usability testing helps me get to know users of the product in a couple of ways. First, if I were helping with the process of selecting participants, I would get to know the characteristics and circumstances of the users. Second, as I watched them perform the tasks in the test, I would get a better idea of how I can provide assistance to them with my documentation.
I don’t have a lot more to say about this one even though it’s a significant factor. Audience analysis and understanding is essential to good user assistance, but it’s something that is easy to leave out when the shackles of the project schedule clamp down. But working usability testing into the schedule will benefit everyone, especially the users if the project team acts on the findings.
The Career Switch
Given the interest we have in the usability of the products we work on, I think a move to usability testing is a natural one. User analysis for documentation can translate to effective finding of participant sample groups. Skills gained from interviewing SMEs help if you’re the one briefing and debriefing test participants. Observation and analysis skills will make your reports and recommendations logically sound.
Most of all, wanting a usable product because you think about those frustrated users provides enthusiasm for conducting fruitful usability testing.
I believe technical communicators and usability specialists have the same goal. It may seem at first glance that these two roles conflict, but only if you’ve adopted the philosophy that documentation isn’t part of the product and the overall usability and positive user experience. However, we’re aiming for the same thing: a product with which users can accomplish tasks as quickly and effectively as possible.
Related posts (auto-generated):
2 Comments to 'Why a Transition from Tech Comm to Usability Makes Sense'
May 13, 2010
Ben, you’ve done a great job of explaining why documentation and usability testing are snyergistic, not incompatible. I agree with and applaud your insight.
May 15, 2010
Hi Ben. It’s nice to hear that some technical communicators are beginning to understand the value of documentation usability testing. To justify the time and expenses required to design and run a usability test, the value of providing customers with more usable product documentation must be driven top-down within an organization to succeed.
Most of the time, trying to build a consensus from the bottom up is just too difficult because important design decisions tend to be made “by committee” (that is, cross-functional team members who are well intentioned but without the benefit of training or actual work experience in usability engineering, software psychology, and modern learning theory).
About ten years ago, when I first began to test my documentation for usability, the opposition from the product cross-functional teams was especially vicious. I finally left usability engineering all together after four years because I got too tired of having to wear a flack jacket for protection all the time.
I haven’t had an opportunity to read your other usability posts, but I recently noticed a book on Amazon called “Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics” published in 2008 that provides a lot of the information that a technical writer would need to know to successfully design, conduct, and analyze data collected from a documentation usability test.
This book describes how to select the best metrics to use depending on which documentation aspects are the most important to measure (for example, whether you want to determine if the process flow of information is logical and easy to follow, measure the completeness of the TOC/index while searching for specific information, or determine how easy/difficult it is to complete all the steps in a complicated procedure. Just some thoughts.
Best regards–David