|
Getting
Started By Carol M. Barnum, Ph.D. Welcome to the usability testing paper (we call this a "course" in the United States, so you may see me use this term, but it means the same thing as "paper"). Yours may be the first course online, so in a number of ways this is a new experience for you as well as for me, as I have not had the experience of lecturing online before. At the same time, as you know, you are one of the first groups of students to use my book Usability Testing and Research, as it is not being published until October. I have classroom tested it with my own students this past semester, but you will be the first to use it outside my own university, and online, as well. So, I will be very interested in your feedback as you work with the book to become knowledgeable about usability testing and to apply your knowledge to the experience of performing a test. I'm excited to hear that you'll be working with a live Web site and that you'll be gaining approval of a sponsor of the site to do the testing and share the results. That will make your work more meaningful to you and certainly valuable for the sponsor (who will profit from receiving free, valuable advice and recommendations for improvements). Before I get into my lecture on the topic of getting started with usability testing, let me introduce myself. Here's what I tell people when I am putting together seminars as a consultant: Carol M. Barnum is a professor of technical communication at Southern Polytechnic State University in Marietta, (Atlanta) GA, USA, a technical communication consultant specializing in custom training and usability, an award-winning author, a top presenter at STC (Society for Technical Communication) annual conferences, a Fellow of STC, and a recipient of STC's Jay R. Gould Award for Excellence in Teaching Technical Communication. She was a member of STC's board of directors for 7 years, 3 years as a Director-Sponsor and 4 years as Assistant to the President for Publications. Her courses in graduate and undergraduate technical communication at Southern Polytechnic include a graduate course in usability testing; her consulting work includes testing hardware, computer-based training, software, and Web sites. Her most recent book, Usability Testing and Research, reflects the focus of her work on usability since 1992. Related books by Barnum include: Techniques
for Technical Communicators, co-edited with Saul Carliner, Macmillan,
1993. Prose and Cons: The Do's and Don'ts of Technical and Business Writing, National (Prentice Hall), 1986. Best of Show, regional STC publication competition, 1986.
Why I Wrote This Book I didn't set out to write a book on usability testing. When I first started teaching a course in usability testing (1993), there was no book on the subject. That shows you how new the field is, and also, by the very large number of books now available on the subject, how fast it has been growing. In fact, if you read the preface to my book, you will understand how much has happened in the last decade regarding usability and its growing awareness in the companies that develop products and in the customers who buy them (but more about this in the next section). I was fortunate at the time I was planning to teach the course to know Ginny Redish, who was completing the first book on usability testing (published later in 1993). She shared an advance copy on the chapter on writing reports and I supplemented that with a list of articles I located on the subject. I was also fortunate in being able to team up with an industry usability consultant, who provided the practical knowledge of the world of usability to supplement the research articles I provided. We made a good team in exposing students to both sides of the world of usability: research and application. An added benefit for my students was that they conducted their usability tests in my co-instructor's lab. Later that year, A Practical Guide to Usability Testing was published (co-authored by Ginny Redish and Joe Dumas), and it became my bible. The following year, another colleague of mine, Jeff Rubin, published his Handbook of Usability Testing, which had some very useful information not covered in the Dumas/Redish book (especially a chapter on the test plan). You will see, as you read my book, that I am heavily indebted to both of these books, as they provided my training wheels to get started teaching and doing usability testing. And I was not alone, for these two books are among the most frequently cited for people interested in the subject, even today. I say "even today" because much has happened since 1993 and 1994 in this rapidly evolving field. When you stop and consider that the World Wide Web was born in December 1990, you realize how dizzying the pace of change, especially the impact of the Web, has been on the world. Can you imagine ever going back to a time before the Web? Because I began teaching my usability course before there was a book and before there were any models for teaching such a course (I knew of only one university where the course was taught), I had to invent and re-invent the course as I went along. As a technical communicator, I knew that usability testing represented an excellent career path for technical communicators, because we have traditionally served as "user advocates" who understand the needs of the user and who frequently have to speak for the users when others won't (or don't). I also knew that usability testing was a "hot topic" as early as the 1992 STC annual conference. So, I knew that our graduate program (the first one in the state of Georgia, USA) should include such a course, and I was interested in learning about the subject. To stay up with the subject meant that I needed to read the growing number of books coming out, as well as the increasing number of research articles. For it is the research that is critical to grounding usability approaches in a proven methodology. This brings me to the question of why I wrote this book. Much as I valued the two books of my predecessors, they were both getting "stale." Publication dates of 1993 and 1994 meant that the authors actually wrote the content for the books one or two years prior to their publication. Dumas and Redish used the introduction of email as their central example in the book (which was a new technology in 1992-3) and Rubin used a printer (as his work experience involved a number of years at Hewlett-Packard). Neither author mentioned the Web, nor did they include any real-world examples. As well, the research on usability testing has grown by leaps and bounds since their books were published. So, I felt
it was time for a new book. Both Ginny Redish and Jeff Rubin had told
me that they would not be doing a second edition of their books, so I
decided that I would do it. As well, there was no book for the growing
number of courses being offered on the subject, so I felt I could address
this audience, as well as a professional audience, and bridge the gap
between academe and industry. Because I was fortunate in being able to
secure funding for a state-of-the art usability lab for my university
(funded through an IBM Million Dollar (U.S.) Total Quality Management
grant, I was using the lab both for my students and for client testing.
As you will see when you progress through the book, I have included examples
from my students, as well as examples from corporate clients. And there
is a chapter on the Web, the hottest topic in usability testing. Why Usability Testing Is Moving Center Stage As I explain in Chapter 1, the advent of "discount" usability testing, based on Jakob Nielsen's research, has a lot to do with the increasing use of usability testing as a part of a user-centered design process. But there's more to it. Usability has now become a competitive advantage for many companies and a marketing mantra. I'll give you an example from a recent client, whose Web-enabled project management system we were testing. When we went to the meeting in which we presented the results to the client, we met the director of sales, who told us that he has been selling the product by telling prospective clients that his company is doing usability testing of the product while it's in development. Two weeks later I read an announcement in the Atlanta newspaper (business section) that this company had sold its product to a very large group of hotels (for whom the project management system is devised). I had to believe that the usability pitch was a part of that sale! But there's more: the Web has really put usability on the map. As I mentioned earlier in this lecture, the World Wide Web is just celebrating its 10th birthday. Although it is understood that usability testing has become important to software companies, it may not really have a significant impact on sales for the following reason: if you buy a product or your company buys a product, you are compelled to use it, especially if you have to, whether it's usable or not. So that explains to some extent why unusable products continue to enter the market. However, the Web is a whole new scenario. You aren't compelled to use most sites on the Web (or any for that matter), and the crash of the dot com market has proven that if the Web site isn't useful, usable, and desirable, customers won't use it. The edge for usability on the Web is that rejection is just a click away. So, Web developers are realizing, more and more, as are the companies that hire the developers, that usability is critical to success. Not only companies but individuals are making usability a part of their vocabulary these days. In the United States, as I'm sure many of you know, the word "usability" was oft-cited in the fiasco of the most recent presidential election. As some of you may have heard me say in the seminar I presented on usability testing in Christchurch in January of this year, the butterfly ballot (the type of ballot used in Palm Beach County, Florida) brought usability into news headlines. At first some blamed "the stupid user," which is a typical knee-jerk reaction when products fail to meet users' needs. Then others began to talk about usability issues. Even though the ballot had been approved by the election committee and published in the newspaper so that voters could see the form of the ballot before voting, the confusion resulting from the ballot was not known until real users used it. Of course, by then it was too late. And the rest is history, as they say. So, problems frequently bring solutions, even if the solutions take place in the proverbial "next release" of the product. That is why usability testing can and should occur at whatever place in the product's development a company is willing to let it happen. As is the case with the products you'll be working with-operational Web sites-it is still not too late for the company to learn, and improve its product. But what's the best way to test a product? By using a team approach, the topic of the last section of my lecture. Why Teamwork Is Important Although
some large corporations (like Microsoft) have usability centers where
testing is conducted by facilitators who schedule the lab and conduct
the test for a development group, it is a more common model to plan, prepare,
and conduct usability testing via a team effort. The reasons for this
are several (as I explain in the appendix in my book): Even though it is a common industry model to use teams, especially cross-functional teams, it is equally well understood that few people prefer to work in teams. Any of you who have had the experience of working in a team, whether for a course or for your employer, have perhaps seen the kinds of problems that can arise when you are dependent on others to share your expectations and your commitment to a successful project. One reason why teams are so commonly used, however, is that the advantages outweigh the disadvantages. And in usability testing, the main deterrent to testing is time. With the advantage of speed, teams beat the abilities of any individual in being able to get the job done in less time. Even if you have had many experiences working in teams, this may be the first time you have been asked to consider your role in a team, as well as that of others, and to analyze group process issues as a way to focus your attention on what happens in groups and to learn from that analysis. Many, many courses in technical writing, and certainly most of the text books, recognize the importance of doing this analysis by including a chapter on working in teams and classroom exercises to support teamwork and the analysis process. When I first taught usability testing (with my co-instructor from industry), I thought that I could assume that my students (most of whom were currently working in the field) would have already become seasoned team players and would therefore not need any instruction, exercises, or support for team-learning activities. I found that I was wrong in my assumptions. Subsequently, I have always given a lecture about team issues and that is why I have now included much of this information in the appendix to my book. With the increased challenge for many of you of conducting a team project long distance, you represent the new model that organizations are going to be adopting, or already are using, as teams are composed of people in diverse environments: some working in the office, some working out of their homes, some working in other cities, and of course some working in other countries. CONCLUSION I hope that
this opening lecture gives some useful information to support the exciting
undertaking you are about to embark on. I'm eager to hear your ideas,
your questions, and your comments as you work your way through the book. 1. Many companies mistakenly claim that their products have been usability tested when, in fact, they have passed inspection for quality assurance. What are the differences between usability and quality assurance? What words would be on a list under the term "usability" and what words would be under the term "quality assurance"? Are there any words that belong on both lists? 2. In considering Web sites for your product, in what ways are Web users different from users of other products? If your Web site also has a physical presence, how would users of the Web be different from those who go to the store or talk to someone on the phone? How does information on the Web need to be designed differently to accommodate the needs of these users?
Questions?
Comments? Contact Dr. Barnum at cbarnum@spsu.edu |