Reading #10: Chapter 12

Chapter 12 deals with evaluating the usability of artifacts, or more appropriately, usability testing. I found it interesting that this chapter comes before chapter 13 which deals with developing a document or artifact that would then go on to be tested, but oh well. I also think that the book overuses the word heuristic to the extreme. I had never heard that word used until I picked up this book, and I wouldn't be surprised if actual technical communicators never use it either. This raised another important question, which relates back to the descriptive/prescriptive approach:  this book is full academic writing, and for the most part prescriptive in it's examples. So what happens in the real job sites, meeting rooms and other associated places with technical writers who are actually writing in the fields? You can study this book's recommendations to death, but if the people working in the real world speak a different language, how does that help? At the end of the day, any exposure to the inner workings of companies is beneficial I suppose. The chapter mentions that the effectiveness of a document depends on how well it connects with its audience, and I think that this is an important notion. Everything in tech writing depends entirely on the audience, as we have covered before. Three types of testing are mentioned:  cognitive walkthroughs, in which a specialist performs predetermined tasks using the document and gathers data on how well the tasks can be performed, expert reviews, in which experts review the document, and heuristic evaluations, in which rankings are assigned to how well the document meets various criteria. I found it interesting that if the document is incomplete in anyway, testing will be unable to discover all the issues that might arise with full testing. Two different types of testing were discussed, dealing with tests that are conducted in the early stages of document development, formative, and testing taking place at the end of development, summative.