Friday, October 14, 2005
22 tomorrow
Christopher and I are running 22 tomorrow - our longest run of the training regimen. We ran 20 week before last. I seem to be out of my training doldrums. And the weather's turned cooler - thanks goodness.
Usability – full-time work for the expert; part-time work for the vigilant technical writer
Here's an article I wrote for the Carolina Communique, our local STC newsletter.
We became technical writers for different reasons. One reason many of us share is that we enjoy expressing ourselves. The irony here is that technical writing affords little opportunity for self expression. 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.
It’s understandably hard when we realize that 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 or product. 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. The definition of usability my organization has adopted is “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 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 a lot of effort. 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, 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 is that as you’re designing an administrative interface for a large system, it will be 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, because 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.
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.
And of course, you can get involved with STC’s Usability and User Experience SIG
We became technical writers for different reasons. One reason many of us share is that we enjoy expressing ourselves. The irony here is that technical writing affords little opportunity for self expression. 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.
It’s understandably hard when we realize that 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 or product. 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. The definition of usability my organization has adopted is “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 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 a lot of effort. 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, 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 is that as you’re designing an administrative interface for a large system, it will be 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, because 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.
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.
And of course, you can get involved with STC’s Usability and User Experience SIG
Subscribe to:
Posts (Atom)
