By Saul Carliner
As most organizations currently use them, Reader's Comment Forms primarily serve as Reader's Complaint Forms. Most just ask readers to report errors in the text, citing location of the error, describing the error, and suggesting a change.
What a waste!
Reader's Comment Forms potentially can provide readers' feedback on all aspects of a technical publication. But because the forms typically do not ask for the feedback, readers don't provide it. Furthermore, because most technical communication groups rely almost exclusively on inbound comments (that is, comments submitted when readers choose to do so rather than when we ask for the feedback), the comments typically provide distorted feedback, usually representing extremes of views (and then, mostly negative).
So how can you make your Reader's Comment Forms work more effectively for you? Read on.
Often, the way that readers feel about a communication product affects their performance with it and their ultimate acceptance of the product, service, or concept that it describes. By asking a broad range of questions about the communication product, you also receive some insights into readers' general feelings about the product that you support.
When formulating the questions for a Reader's Comment Form, consider asking the ones that are described in the following sections.
The first two questions seek users' overall impressions of the communication product.
Logic behind questions 1 and 2: Asks users to express in words and numbers their response to your documentation. Words provide a mirror into their real feelings, while numbers provide a quantifiable, trackable measurement.
By asking for both words and numbers, you can also assess whether the numbers are correct. For example, if a reader describes a communication product as "Extremely useful," but gives it a numeric rating of 1, the reader probably transposed the scales when responding.
Also, by using extreme words to represent the extremes of the scale, readers can better differentiate among the numbers and the novelty factor of the words interests them in responding.
Finally, note the term communication product. This is a generic term for a published work. Feel free to replace it with a term that better describes your communication product, such as user's guide, help system, tutorial, or reference.
The next three questions explore various aspects of the usability of the technical communication product.
Logic behind the question: This question gives you a sense of how people really use the communication product. Use this knowledge when designing future editions.
|I can't||Average usually after a few moments||Easily within seconds|
Logic behind the question: One of users' biggest complaints and one of the most extensive areas of research is how quickly and easily readers can find information. Asking for feedback on this issue tells you whether readers can easily find information in your communication product.
|Not at all.||Sometimes I can, but occasionally I find the content confusing||With great ease|
Logic behind the question: Readers often complain that the content confuses them. Get a sense of how much by asking about it.
The next question, a two-parter, asks users to assess how much they have learned from the technical communication product.
|Not at all||A bit||Thoroughly|
After reading this guide?
|Not at all||A bit||Thoroughly|
Logic behind the question: Find out whether readers feel that the communication product is helping them to better understand the product.
The last two questions seek answers to open questions about the communication product.
Logic behind the last two questions: The last two questions provide qualitative feedback on the communication product and help prioritize work in a revision. Items that are mentioned on several responses warrant attention. For example, if 10 readers respond that the examples are excellent, then you should probably incorporate examples like these in similar communication products. Similarly, if 18 readers comment that they have difficulty finding information in the guide, then you should probably strengthen the section titles, table of contents, running headers, and index in a future edition.
Saul Carliner is a visiting assistant professor at the City University of Hong Kong. His books include Designing E-learning, An Overview of Online Learning, and Techniques for Technical Communicators. He is a fellow and past international president of the STC, and a former member of the Boston chapter.