You are here: Articles --> 2003 --> "Prescriptive" audience
Vous êtes ici : Essais --> 2003 --> "Prescriptive" audience analysis
by Geoff Hart
Previously published as: Hart, G.J. 2003. "Prescriptive" audience analysis: moving beyond the purely descriptive. http://www.techwr-l.com/techwhirl/magazine/writing/prescriptiveanalysis.html
Editing and writing both require an understanding of our audience, because without that knowledge, we can't shape our words to help readers to easily grasp difficult concepts. To understand our audience, we do what all writers and editors do, whether consciously or unconsciously: We create an image of our audience that guides our choice of words, images, and metaphors. This image is variously known as a "stereotype" (e.g., Schriver 1997) or a "persona" (e.g., Graham 2001). Keeping that image in mind as we work helps us satisfy the reader's needs, but if we're not careful, it can also cause us to waste valuable time collecting information that doesn't really help us communicate.
Instead, as technical writers, we should take a prescriptive approach to audience analysis, which focuses on what we should write about, rather than on how we can write in terms the audience understands. This approach emphasizes that clear, effective writing will communicate with any audience, whatever their characteristics. It also emphasizes that we should start with the problem the audience is trying to solve, rather than starting by analyzing audience characteristics.
This article begins by identifying some key terminology and distinctions, then describes the prescriptive approach and its applications for technical writers. In particular, you'll see the following:
Stereotype and persona have similar denotations (dictionary definitions) and are sometimes used interchangeably, but they have very different connotations (assumed meanings):
Knowing the roles that our readers adopt tells us much about how they use the tools we're documenting. For example, when I write for Intercom, I'm writing for people with whom I share a role: solving communication problems. Thus, Intercom readers and I adopt the same role (technical communicator), and to some extent, if I can understand the text, my audience should understand it too. Of course, our roles also differ significantly in some ways; the fact that I'm writing this article and you're reading it suggests that I'm more familiar with the material and shouldn't assume too much knowledge on your part.
Many audience analyses fail because they provide only the kind of descriptive information in the first part of my example: "We're all technical writers here." Such purely descriptive information fails to meet our needs because it's not inherently prescriptive: It doesn't identify the problems we must solve for our readers. Because the results clearly tell us what to write about (solutions to those problems), I call an analysis that focuses on identifying problems prescriptive—it prescribes what me must do. At the 48th annual STC conference, I presented a paper (Hart 2001) that discussed how a purely descriptive analysis can generate superficial stereotypes, whereas focusing on the reader's role and the problems posed by that role can be more effective.
Prescriptive analyses differ from descriptive ones in the focus each approach adopts: Descriptive information describes our audience rather than the problems they face. An example will make this clearer. One common descriptive measure of an audience would be the proportions of relatively old and relatively young readers. Unfortunately, this information evokes a simplistic stereotype: Because visual and auditory acuity inevitably decline as we age, older readers are going to have difficulty reading our text or hearing narrations in multimedia information.
Examining this common stereotype reveals its obvious flaws, most importantly that visual and auditory impairments afflict people of all ages. But considering the roles our readers adopt (reading and listening) clearly reveals the problems that we must solve:
Understanding the problems faced by those who adopt the roles of reader and listener reveals one typical problem we must solve: that modern window-based interfaces and multimedia information prevent blind readers from using traditional screen-reader software and rob the deaf of important auditory cues. If, as many of us now do, we include complex text formatting (e.g., multiple columns) or narration in our online help or Web pages, we must provide alternative forms of this information for those who cannot use the standard presentation.
It's important to note that although I've focused on a prescriptive approach, this by no means negates the value of descriptive data; in fact, the two are complementary. A prescriptive approach focuses on what we should write about, whereas a descriptive approach focuses on how we can better write in terms the audience understands. My emphasis on a prescriptive approach is based on the rationale that the clear, effective writing we're all capable of will communicate well with any audience, whatever their characteristics; however, if we don't explain everything that readers must know to perform their tasks (i.e., if we don't identify all the problems they face and present solutions), even the most audience-appropriate writing (based on a descriptive analysis) fails to meet reader needs. In a practical sense, this means that when we perform an audience analysis, we should start by identifying all the problems readers will encounter in performing a task and set about solving those problems for them. Subsequently, if time permits, collecting descriptive information will let us polish what we've written to better meet their needs.
It's helpful to understand the main types of audience analysis currently in use, because each can prove useful as part of an integrated (prescriptive plus descriptive) approach to audience analysis. Karen Schriver (1997) described three main types:
Although the three approaches are often considered separate and distinct—following the regrettable human tendency to treat a single useful and elegant solution as universally applicable—Schriver notes that we can use different approaches at different times. In fact, I'd go one step further and suggest that we can obtain the best results by using elements of all three approaches at different stages of an audience analysis. For example:
Refining designs through iteration (repetition of the steps) is an important way to develop effective documentation. Thus, the "listening" step isn't so much a true conclusion as it is a resting point before we start over again. The feedback obtained by listening tells us whether we must create new personas or refine existing ones and whether different classes of reader require different solutions. Having come up with a new design, we finish once again (for the moment) by once again testing the resulting documentation with real users. Through iteration, we develop progressively better personas that reveal what users want to do with our product, how they want to do it, and how we can help them do it.
This approach resembles usability testing of software and hardware interfaces, but focuses on the usability of documentation (its success in creating understanding for the reader) rather than that of the product. This approach is also similar to how programmers develop "use cases" (e.g., Ham 1998), but use cases typically focus more on the design of software architectures than on user-interface issues. I won't explore the relationships between audience analysis, usability testing, and use cases any further, other than to note that the parallels between these activities suggest the potential of using insights from one field to improve the practice of the others.
Audience analyses gain considerable power when they start out with a clear focus on the details of the tasks that the audience performs. Once you identify solutions to the specific problems that users encounter (prescriptive analysis), you can subsequently collect data that suggests the best way to communicate those solutions (descriptive analysis). For example, adopting the persona of someone who must change a flat tire reveals that this role requires considerable strength; identifying the importance of strength in this task suggests that our documentation should provide solutions for readers who aren't strong enough to remove a wheel using only the provided wrench. One such solution might be the suggestion that readers purchase strength aids (e.g., a metal pipe that fits over the end of a wrench and increases the user's leverage). Of course, we might also suggest that the manufacturer provide a better wrench in the first place.
An analysis that begins with a prescriptive approach and concludes with a descriptive approach could follow four simple steps:
An example illustrates how this approach actually works in practice. Writers commonly believe that our audience uses online help only reluctantly, and respond by spending considerable time improving the quality of our help systems. A help system may certainly be badly written or badly designed, so efforts to improve our help design and creation skills remain important, yet improving help files sometimes targets the wrong problem. Speaking at STC's 48th annual conference, one speaker confirmed what I've found in my own work by reporting four reasons why our audience may not use online help. Two are relevant to my example:
This demonstrates how adopting a persona ("I've encountered a problem and want to learn how to solve it") can lead to an important solution: By taking on the user's role, we discover that we must first decide where to seek help (for online help, we must know that such things exist), then must figure out how to use it. Without adopting the role of a user of the help system, we might simply assume that our audience knows that help exists and understands how to use it. A prescriptive approach to this situation could proceed as follows:
That's elegant in theory, but does it work? This approach led me to include a section on how to use online help in the user manuals for the past two products I've documented. Moreover, I persuaded our trainer to incorporate a brief lesson on using the help system during his training sessions. The results have been excellent thus far, since our clients now use our software without requiring extensive technical support—a good thing, since we don't have any full-time support staff. Moreover, we've received favorable feedback on the usefulness of our help systems.
It's likely that over time, our audience will become familiar with online help or the technology itself will improve sufficiently that this training will no longer be necessary. Ongoing contact with our audience will reveal when we no longer have to include these explanations in our manuals or perform this training.
It's easy to come up with additional examples. For example, one of the most common stereotypes we invoke is that of the "new user" versus the "expert". In fact, for most product features, both classes of user have identical needs: they use the same mouse, the same menu, and the same dialog box to accomplish a given task. This suggests that stereotyping users based on their expertise fails to attack the most important problem; adopting a persona based on the user's role ("any user must accomplish this task by following the same basic steps") lets us explain clearly and effectively how to do the task, irrespective of the user's expertise.
Although that approach produces useful documentation, it doesn't produce the best documentation possible. If we have time to conduct a descriptive analysis, we'll probably discover that expert users want shortcuts or more detailed information than new users want, need, or can use. We can use this knowledge to improve our documentation by incorporating a list of shortcuts and more detailed reference material in our documentation. What's important to note is that even if we don't obtain this descriptive information, and only concentrate on writing clear instructions for all possibilities, we've produced good documentation. The examples I've presented show how purely descriptive audience analysis remains useful, but primarily as a second step in a more focused "prescriptive" analysis that first identifies the problems.
Don't use this approach unchanged in every situation; doing so turns it into a formulaic solution that eventually stops reflecting audience needs. The approach must always be subject to a reality check in the form of re-evaluating the personas you've created and revising them when they're no longer valid. Audiences change over time, and your analysis needs will change in response. Once you characterize an audience thoroughly, you may only need to focus on aspects of the approach that confirm the validity of the personas you've created. For example, if you're documenting a mature product with a stable audience, the listener's feedback-based analysis may become the most important means of confirming that your information continues to meet audience needs.
However, developers tend to add new features or change how existing features work, and when that happens, you'll need to determine whether this changes the roles users adopt and the consequences of those changes for the documentation. When your Marketing department introduces that same product to a new market, you should repeat the entire analysis to determine whether the new users adopt new personas; the existing information should continue to meet the needs of existing audiences. Both cases suggest a slightly different approach than the one you'd use for the stable product and audience.
Graham, B. 2001. Identity crisis: the persona as a tool for formulating and evaluating information design. Presentation (progression) at the 48th Society for Technical Communication Conference, 13–16 May 2001, Chicago, IL.
Ham, G.A. 1998. Four roads to use case discovery. There is a use (and a case) for each one. www.stsc.hill.af.mil/crosstalk/1998/dec/ham.asp
Hart, G.J. 2001. Audience analysis: looking beyond the superficial. p. 105–107 in: Proceedings, STC 48th Annual Conference, 13–16 May 2001, Chicago, Ill. Soc. Tech. Comm., Arlington, Virg. 608 p.
Schriver, K.A. 1997. Dynamics in document design. John Wiley and Sons, Inc., New York, N.Y. 560 p.
This article went through multiple revisions in response to feedback from STC audiences for my presentations on this topic, but would not have achieved anything like its present clarity and focus without the insight and persistence of Ed Rutkowski.
©2004–2017 Geoffrey Hart. All rights reserved