Looking for something?
full-time work for the expert; part-time work for the vigilant technical writer
By Michael Harvey, Past President, Carolina Chapter
We became technical writers for different reasons. Many of us did so because we enjoy expressing ourselves. The irony is that technical writing affords little opportunity for selfexpression. We can make up for that by taking pride in the clarity and concision of our work. We can claim to be vigilant advocates for "the user" as we transmute jargon into understandable prose.
That advocacy notwithstanding, the audience for whom we toil has little interest in reading what we produce. In fact, most of the time, our audience reads what we write only as a last resort. They peruse our prose only when the application or the system didn't lead to the expected result. It's our responsibility to write crisp information and to provide adequate context that allows readers to find it as soon they need it, comprehend it quickly so as to act effectively, and get back to work.
Congruent with that responsibility is one to become familiar with the subject of usability. In my organization, usability is defined as "a design attribute that characterizes the effectiveness, efficiency, and satisfaction with which users can accomplish desired tasks with a product." Determining the usability of something means asking whether someone can figure out what to do with it, what's going on at the moment, what, if anything, is going wrong, and what to do next.
It's easy to make something unusable, as Donald Norman illustrates in his book The Design of Everyday Things:
It's hard, though, to make something truly usable.
The January 2005 issue of Intercom focused on usability and the user experience design. One article spoke of the trends that "usability practitioners" should consider, suggesting to me that technical writers may consider themselves usability practitioners. Usability experts and technical writers share a passion for customer advocacy. My own immersion in the subject leads me to conclude that you can be a full-time technical writer knowledgeable about usability, or you can be a full-time usability expert knowledgeable about technical communication, but you cannot be a full time technical communicator/usability expert. You do both professions a disservice if you try.
Earlier this year, I attended a Usability Boot Camp run by Bentley College. The most important thing I learned during that intensive one week program was that usability, done correctly, is a full time job. Each aspect of usability can in fact lead to a different full time job-you can be a full-time user-centered designer, or a full-time expert in gathering and evaluating customer requirements, or a full-time usability tester, or a full-time data analyst. Some companies go all out (think Apple) and thus have a devoted customer base (think iBook or iPod). Most companies don't invest this heavily into usability, and expect a smaller staff to implement it in their development process. Either way, it requires someone's full-time attention to do it justice.
Developing a set of core tools for implementing usability during the development process requires time. The core tools are:
Personas are fictional characters whose personal and professional characteristics closely match those of real customers. They can be personal descriptions, with names, families, and college allegiances, all to make them as real as possible. They represent groups of users, not just a single individual. A key ingredient of a persona is her or his goals. For example:
Joe is a system administrator for a 300-person company. He's 30 years old, married, and has no children. He's got 10 years of experience. He went to college for two years and quit when the part-time system administrator job that he had as a student became a full-time position. He works about 10 hours a day, 5 days a week, even though he's expected to respond to emergencies at any hour. He wears a cell phone on his belt and it goes off at least four times a day. He would love to get caught up on his project work (upgrading the server, installing new applications, swapping out old network hubs, and so on), but he doesn't expect to ever get the time. Every day he's interrupted in his project work by folks asking him to solve their specific problems. He's an expert in Windows, and knows a little bit about Unix. He works with two other technicians who informally report to him; they serve 500 PCs networked into two clustered servers. When he's not working, he likes tinkering with his Harley and riding it in the mountains.
The idea behind personas is, as you're designing an administrative interface for a large system, it is easier to design for Joe rather than for "the administrator." Alan Cooper makes a strong case for personas such as these in his book, The Inmates are Running the Asylum.
Heuristics are guidelines written in everyday language that help verify that you're meeting specific usability criteria. One of the most important characteristics is that they are measurable. "Is it easy to use?" is impossible to measure in a repeatable way, but "Is the system status clearly visible?" can be measured precisely.
Heuristics can be applied to different aspects of a product, such as the user interface, error messages, or the installation process. Here are some sample heuristics for error messages:
Usability testing is a process by which you observe or interview real users as they interact with live systems, prototypes of systems, or paper mockups of systems. Users are given goals to achieve and are facilitated by someone as they attempt to achieve them. Tests are often recorded or transcribed for detailed analysis afterwards. In some tests, users are encouraged to think aloud as they work through the problem. Analysis of the tests should reveal what contributed to the success of the participant and what inhibited success in achieving the goals.
You don't need a formal lab to conduct usability tests; you can use portable equipment in the customer's environment or you can use paper mockups in any available conference room. While I was at Bentley's Usability Boot Camp, I watched one of the instructors perform a usability test on Quicken in our classroom. Someone unfamiliar with the application attempted to add an account, make a deposit, write three checks, and list transactions of a particular category. The participant thought out loud as she tried to perform each of those tasks. The professor, in a non-directive way, kept things on track. Because I'm experienced with Quicken, I was surprised to see someone struggle. I imagine most engineers who are experienced with the applications they produce would be surprised by the results of usability tests on their products.
Even though putting these core tools together into a successful usability regimen is not a part-time job, technical communicators can serve valuable part-time roles in contributing to its success. We can help run the usability tests. We can record and help analyze the data. We can review and comment on heuristics. We can help implement heuristics by, for example, editing or rewriting error messages. We can help flesh out personas. We can interview customers to gather characteristics that would help lead to representative personas or usability criteria. We can help make sure that the ideas that usability experts need to communicate to those who actually build the product are clear, concise, and complete.
The more intuitive a product's interfaces and procedures become, the more usable it becomes. Thus, the less formal documentation it requires. To do our part, we can strive to reduce the number of words a customer needs to read. Focusing on clarity and concision, we can take pride that of the words that remain, every word will count. Working with usability experts, our fellow customer advocates, we can transmute unwieldy products into easily used ones. To me, that's a compelling reason to remain a technical communicator, regardless of why we became one.
Want to know more about usability? Start with these books:
Then check out the following resources available on the Internet.
And of course, you can get involved with http://www.stcsig.org/usability/ STC's Usability and User Experience SIG.
Michael Harvey can be reached at mtharvey@yahoo.com.
By Michael Harvey, Past President, Carolina Chapter
Michael Harvey
That advocacy notwithstanding, the audience for whom we toil has little interest in reading what we produce. In fact, most of the time, our audience reads what we write only as a last resort. They peruse our prose only when the application or the system didn't lead to the expected result. It's our responsibility to write crisp information and to provide adequate context that allows readers to find it as soon they need it, comprehend it quickly so as to act effectively, and get back to work.
Congruent with that responsibility is one to become familiar with the subject of usability. In my organization, usability is defined as "a design attribute that characterizes the effectiveness, efficiency, and satisfaction with which users can accomplish desired tasks with a product." Determining the usability of something means asking whether someone can figure out what to do with it, what's going on at the moment, what, if anything, is going wrong, and what to do next.
It's easy to make something unusable, as Donald Norman illustrates in his book The Design of Everyday Things:
- Give no hints about what to do
- Provide no feedback and no visible results of actions just taken
- Fail without indication or explanation
- Use obscure command names
- Provide uninformative error messages
- Let something be done one way in one place and another way somewhere else
- Make operations dangerous by allowing a single mistake to destroy work
It's hard, though, to make something truly usable.
The January 2005 issue of Intercom focused on usability and the user experience design. One article spoke of the trends that "usability practitioners" should consider, suggesting to me that technical writers may consider themselves usability practitioners. Usability experts and technical writers share a passion for customer advocacy. My own immersion in the subject leads me to conclude that you can be a full-time technical writer knowledgeable about usability, or you can be a full-time usability expert knowledgeable about technical communication, but you cannot be a full time technical communicator/usability expert. You do both professions a disservice if you try.
Earlier this year, I attended a Usability Boot Camp run by Bentley College. The most important thing I learned during that intensive one week program was that usability, done correctly, is a full time job. Each aspect of usability can in fact lead to a different full time job-you can be a full-time user-centered designer, or a full-time expert in gathering and evaluating customer requirements, or a full-time usability tester, or a full-time data analyst. Some companies go all out (think Apple) and thus have a devoted customer base (think iBook or iPod). Most companies don't invest this heavily into usability, and expect a smaller staff to implement it in their development process. Either way, it requires someone's full-time attention to do it justice.
Developing a set of core tools for implementing usability during the development process requires time. The core tools are:
- Personas
- Heuristics
- Usability testing
Personas are fictional characters whose personal and professional characteristics closely match those of real customers. They can be personal descriptions, with names, families, and college allegiances, all to make them as real as possible. They represent groups of users, not just a single individual. A key ingredient of a persona is her or his goals. For example:
Joe is a system administrator for a 300-person company. He's 30 years old, married, and has no children. He's got 10 years of experience. He went to college for two years and quit when the part-time system administrator job that he had as a student became a full-time position. He works about 10 hours a day, 5 days a week, even though he's expected to respond to emergencies at any hour. He wears a cell phone on his belt and it goes off at least four times a day. He would love to get caught up on his project work (upgrading the server, installing new applications, swapping out old network hubs, and so on), but he doesn't expect to ever get the time. Every day he's interrupted in his project work by folks asking him to solve their specific problems. He's an expert in Windows, and knows a little bit about Unix. He works with two other technicians who informally report to him; they serve 500 PCs networked into two clustered servers. When he's not working, he likes tinkering with his Harley and riding it in the mountains.
The idea behind personas is, as you're designing an administrative interface for a large system, it is easier to design for Joe rather than for "the administrator." Alan Cooper makes a strong case for personas such as these in his book, The Inmates are Running the Asylum.
Heuristics are guidelines written in everyday language that help verify that you're meeting specific usability criteria. One of the most important characteristics is that they are measurable. "Is it easy to use?" is impossible to measure in a repeatable way, but "Is the system status clearly visible?" can be measured precisely.
Heuristics can be applied to different aspects of a product, such as the user interface, error messages, or the installation process. Here are some sample heuristics for error messages:
- When an error occurs, is the person informed of it and of what stage of the operation the error was detected?
- Does the error give a clear indication of the underlying problem?
- Does the system tell the person how important the error is and what will happen until the underlying problem is fixed?
- Does the message suggest specific actions to fix the underlying problem?
- Is the message complete enough that the person doesn't have to refer to another document to know what the message means or what to do?
Usability testing is a process by which you observe or interview real users as they interact with live systems, prototypes of systems, or paper mockups of systems. Users are given goals to achieve and are facilitated by someone as they attempt to achieve them. Tests are often recorded or transcribed for detailed analysis afterwards. In some tests, users are encouraged to think aloud as they work through the problem. Analysis of the tests should reveal what contributed to the success of the participant and what inhibited success in achieving the goals.
You don't need a formal lab to conduct usability tests; you can use portable equipment in the customer's environment or you can use paper mockups in any available conference room. While I was at Bentley's Usability Boot Camp, I watched one of the instructors perform a usability test on Quicken in our classroom. Someone unfamiliar with the application attempted to add an account, make a deposit, write three checks, and list transactions of a particular category. The participant thought out loud as she tried to perform each of those tasks. The professor, in a non-directive way, kept things on track. Because I'm experienced with Quicken, I was surprised to see someone struggle. I imagine most engineers who are experienced with the applications they produce would be surprised by the results of usability tests on their products.
Even though putting these core tools together into a successful usability regimen is not a part-time job, technical communicators can serve valuable part-time roles in contributing to its success. We can help run the usability tests. We can record and help analyze the data. We can review and comment on heuristics. We can help implement heuristics by, for example, editing or rewriting error messages. We can help flesh out personas. We can interview customers to gather characteristics that would help lead to representative personas or usability criteria. We can help make sure that the ideas that usability experts need to communicate to those who actually build the product are clear, concise, and complete.
The more intuitive a product's interfaces and procedures become, the more usable it becomes. Thus, the less formal documentation it requires. To do our part, we can strive to reduce the number of words a customer needs to read. Focusing on clarity and concision, we can take pride that of the words that remain, every word will count. Working with usability experts, our fellow customer advocates, we can transmute unwieldy products into easily used ones. To me, that's a compelling reason to remain a technical communicator, regardless of why we became one.
Want to know more about usability? Start with these books:
- Cooper, Alan. The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. SAMS, 1999.
- Nielsen, Jakob. Usability Engineering. Morgan Kaufmann, 1994.
- Norman, Donald A. The Design of Everyday Things. New York: Basic Books, 1988. (2002 Edition)
- Rubin, Jeffrey. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. Wiley, 1994.
Then check out the following resources available on the Internet.
And of course, you can get involved with http://www.stcsig.org/usability/ STC's Usability and User Experience SIG.
Links
Usability
- ACM SIGCHI
- Usability Consortium
- Usability Professionals' Association
- Usability Views
- Usability Net
- Usability.GOV - basics, methods, guidelines
- Usability Toolkit - Heuristics, from the STC
- Suggested Readings for Usability Testing (bibliography)
- Usability Testing Methods & Tools (University of Maryland)
- IBM Ease of Use
Section 508
- W3C Web Content Accessibility Guidelines 1.0
- Electronic and Information Technology Accessibility Standards (Section 508)
- Web Accessibility Evalutation Tools
(screen readers, audio browsers, page checkers, and more) - Section 508 Accessibility Resources (NOAA National Weather Service)
General User Interface
- Task-Centered User Interface Design
- Samuel Wan's Flash-based "fisheye" interface
- MSDN User Interface Design & Development
- Achieving Usability Through Software Architecture
- User Interface Books
- Human-Computer Interface
- User Interface Design & Usability Testing
- Usable Web: portal to 970 links about web usability
- Web-based UI Evaluation with Questionnaires
- GUI Design Handbook
Michael Harvey can be reached at mtharvey@yahoo.com.
Top of page
Staff and authors:
