"Prescriptive" audience analysis: moving beyond the purely descriptive

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:

Differences between stereotypes and personas
Differences between descriptive and prescriptive information
Types of audience analysis
A prescriptive approach to audience analysis
Advice for applying the prescriptive approach in the documents we produce

Stereotypes vs. personas

Stereotype and persona have similar denotations (dictionary definitions) and are sometimes used interchangeably, but they have very different connotations (assumed meanings):

Stereotypes can be "oversimplified opinions, affective attitudes, or uncritical judgments", and therein lies the problem: They can mislead us by oversimplifying a complex situation, by provoking an affect (emotional response) in us, or by lulling our critical judgment to sleep.
Personas, in contrast, reflect the role that someone is playing (the tasks they must perform). Given that much technical writing involves describing how to perform tasks, personas are more broadly useful to us than stereotypes.

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.

Descriptive vs. prescriptive information

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:

The role of reader tells us that our audience must be able to read the textual part of our documentation, and that we must therefore make the documentation legible. Because legibility is important, we must ask whether some audience members inherently have problems with what most of us consider the simple act of reading.
The role of listener tells us that our audience must be able to hear spoken words or other sounds that we use. Thus, the ability to discern sounds is important for any aspect of our communication based on sound.

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.

Types of audience analysis

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:

Classifiers identify the types of audience characteristics or features that might be important, develop an audience profile made of several "classes" based on these characteristics, and use that profile as a target in designing documentation.
Intuitors pretend to be audience members, take on their roles, and pay close attention to their reactions and experiences in performing those roles. Understanding these reactions and experiences provides strong clues to what they should write, and how.
Listeners investigate actual audience members, identify that audience's feelings about a situation (e.g., performing a task) and the skills they bring to that situation, then test their assumptions by producing trial solutions for the audience to review.

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:

Begin with an "intuitive" approach: Adopt the roles of several audience member (take on their personas) and imagine what their needs might be; for example, some users may manage a network while others only use the network. This step begins to identify the tasks users face and the problems they encounter in performing these tasks.
Continue with a classification approach: Classifiers often go beyond standard descriptive information to include psychographic factors such as knowledge when they define classes within an audience (e.g., beginners and experts). These classes build on the problems identified by the intuitive approach by revealing whether we require multiple solutions to a problem (e.g., one for beginners, another for experts).
Conclude with a "listening" approach: Incorrect assumptions lead to designs that seem suitable but that don't actually work as well as we hope. Direct feedback from our audience identifies where we must improve our image of the audience, and in particular, which needs we failed to satisfy.

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.

A prescriptive approach to audience analysis

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:

Perform a quick and simplistic audience analysis (an "environmental" or "contextual" assessment) to identify the environment or context in which the task is performed.
Identify the particular problems or communications challenges faced by someone working in that context (i.e., establish a persona for the product's user that prescribes what we must write about).
Perform an audience analysis focused on those challenges to determine which audience members or classes of members will encounter those problems, and why (i.e., collect descriptive information that tells us how to write).
Identify potential solutions to the problems, implement them, and test them to confirm that we've actually solved the reader's problems.

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:

Many users don't know that the help system exists.
Those who do know about the help system often don't know how to use it.

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:

Context: Users encounter a problem and must find and use our online help to solve it.
Problem: If we are creating effective help systems, some factors other than the quality of our help must be preventing the audience from using those systems.
Audience analysis: Users of a help system must adopt the role of someone who looks for help, then learns how to use it once they find it. Not all users can succeed; some don't know online help is available and others don't know how to use it.
Preliminary solution: Teach users how to use the online help, then test whether this encourages them to use it.

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.

Start with the problem, not the user

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.

References

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.

Acknowledgments

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.