Personas and the five W’s: Developing Content that Meets Reader Needs, Pt. 1

Part I: What’s a persona?

BatmanMost documentation written by professional writers, whether printed or online, is well written and easy to navigate, but in my experience, an unfortunately high proportion omits important content or provides inadequate depth of content. Worse yet, the information may seem perfectly acceptable from a textbook perspective, yet fails to reflect the conditions under which the information will be used. These problems often arise from a lack of understanding of the audience for whom we’re writing, in many cases because we have done an audience analysis that:

  • focused on demographics rather than a realistic portrayal of the audience
  • ignored the physical and emotional context in which the audience works
  • emphasized product features rather than audience goals and needs
  • ignored factors that arise from interactions among audience, context, and goals

The solution is as easy to state as it is difficult to implement: we must understand our audience sufficiently well, before we begin writing, that we can determine the information they require, any context-related constraints that will interfere with their use of the information we create, and any context-related success factors that can help them use that information more successfully. There have been many different approaches to solving this problem, ranging from task analysis to “use cases“, and each has its merits and demerits. But a relatively recent approach called “personas”, designed originally to support product development and subsequently expanded for use in usability testing, potentially produces a superior analysis because it is more focused on real people and their real needs. The concept of personas was first codified by Alan Cooper, and is described in his book The Inmates are Running the Asylum.

So what is a persona?

The persona approach to developing documentation is a form of audience analysis that focuses on describing real people, rather than defining useless demographic categories that only hint at who these people are, their needs, and how their work environment affects those needs. You can see the power of a persona compared with a stereotype through a simple example:

  • Useless stereotype: Our typical audience member is a university-educated, physically fit, single white male, 30 years old, who works as a wealthy industrialist. He drives a luxury car by day to support his work life, and a Hummer-type “urban assault vehicle” at night to support a second career as a crime fighter.
  • Useful persona: Bruce Wayne is a wealthy industrialist, orphaned at a young age, who pretends to be a gentleman of leisure by day, but by night, he is a master martial artist, detective, and scientist–engineer who fights crime and invents and uses complex weaponry. A chronic lack of sleep plus the distraction of having to ponder the future actions of a range of exceptionally intelligent and highly dangerous supervillains means that he is usually sleep-deprived and mentally distracted during the day. At night, in his Batman role, he has little time to think, and must rely on his wits and his superhuman reflexes: conflict with his many enemies forces him to rely extensively on computer support for his crime-fighting supervehicle, the Batmobile, and on “smart” weaponry. In this situation, he faces many distractions simultaneously, and must often overcome them while badly injured.

Which of the two gives you a better understanding of your target audience? Which gives you a clearer idea of what the person’s documentation needs will be? Clearly, the persona approach works better. It is more detailed and focuses on the person’s needs rather than on socioeconomic and other characteristics that only indirectly hint at those needs. But that’s not all: pretty much any member of a Western culture knows and understands both Batman’s personality and his “work” environment. Because the persona is so familiar, albeit unrealistic, it’s a helpful way to dramatize the example and illustrate the approach to constructing and using a persona.

A good persona has several key characteristics:

  • It names the character, thereby personifying a fictional character and making it seem human. In so doing, it allows us to ask the following question with a reasonable expectation of coming up with the right answer: “What would Bruce do?”
  • A collection of relevant personas lets us contrast Bruce with the personas of others who might potentially use our product: “How would Geoff behave differently?”
  • It emphasizes details of the person’s personality and context that will affect their use of the product we’re documenting—and of our documentation.
  • It offers a narrative, not a series of bullet points. The narrative structure “connects the dots” (the bullets) in such a way that the persona becomes an actor, not a lifeless collection of statistics.
  • It provides enough detail that we gradually come to understand the person and how they will behave.

The Bruce persona I’ve provided is more terse than a real persona should be, but we’ll flesh it out progressively during the remainder of this article. I’ve included several references by Kim Goodwin, one of Alan Cooper’s senior designers, to fill in the details that I can’t provide in the space of a short article.

The result of creating a persona is a vivid image that is instantly recognizable as a human being. Over time, our familiarity with a real persona would increase sufficiently that the person “behind the mask” becomes as familiar to us as Bruce’s Batman persona. Each of us spends many years learning to understand and interact with our fellow humans before we ever encounter the concept of written communication, and we then spend a great many more hours learning to interact successfully with our fellow humans than we ever spend learning to write or polishing our writing. Thus, the use of personas takes advantage of well-honed social skills, both conscious and subconscious, that let us interact successfully with friends, family, and co-workers. Because these skills are so strong, the persona approach can provide unparalleled insights into audiences, thereby letting us empathize with and understand the real people for whom we’re creating information. It also provides a clear understanding of their context: the conditions (physical, emotional, and other) under which they work, and the problems we must solve for them within that context so they can accomplish their various tasks. Personas also help us focus on the tasks, but always from the perspective of the aforementioned aspects of their character and context.

 

Using the five W’s to flesh out the “Bruce” persona

In real-world documentation situations, we would create a detailed description of people who stand in for broadly representative categories of audience member. Typically, it’s only necessary to create a handful of personas to account for the majority of a product’s users. Indeed, creating more than half a dozen or so personas for anything other than the most complicated product may be counterproductive because it complicates the task of analysis beyond what we may be able to handle with the limited resources typically available to most technical communicators. In this article, I’ll describe only a single persona (Bruce, acting in his Batman persona) to avoid complicating the discussion unnecessarily and to help you focus on key details. To further narrow the scope of that discussion, I’ll only consider Bruce’s use of his evening vehicle (the Batmobile) while he interacts with his foes. Don’t forget that if we were doing this analysis for real, we’d also need to consider Batman’s sidekick, Robin, and any other colleagues such as his faithful butler, Alfred, who might want to use the vehicle.

In the short time you’re likely to devote to reading this article, you’re unlikely to become intimately familiar with any new persona that present. To provide enough familiarity that you can explore the power of this approach on your own, I’ve chosen Bruce for my example: the strength and familiarity of his persona compensate for its unrealistic nature and the limited description that I’ve provided.

How do we get to know our persona and use that knowledge to develop better documentation? As I’ve written in previous articles (see the bibliography), the journalistic technique of the five W’s (asking who, what, where, when, and why) is a powerful tool for analyzing a situation. Journalists have been taught a codified version of this approach for nearly a century to ensure that they will capture all the important details in a newspaper article or TV interview, and recognizable forms of the approach go back far longer. Thus, it’s an approach that is proven to work. For more details on the five W‘s, see the Wikipedia article and the bibliography at the end of this article.

In the case of personas, it’s a great tool to guide us in fleshing out a persona in sufficient detail that we can directly meet the needs of the real people it represents. In the specific and clearly limited context of Bruce’s use of the Batmobile, our goal is to:

  • Answer the “who” question by defining a persona. I’ve already done this earlier in this article in my description of Bruce.
  • Answer the “when” and “where” questions by defining the context in which the persona works.
  • Answer the “why” and “what” questions by defining the tasks the persona must accomplish, the reasons for those tasks, and details of those tasks.

In Part II of this article, I’ll answer those final four questions to show you how they can guide our writing efforts.

Further reading

Brechin, E. 2002. Reconciling market segments and personas.

Calde, S. 2004. Using personas to create user documentation.

Cooper, A. 2004. The inmates are running the asylum: why high tech products drive us crazy and how to restore the sanity. Pearson Publishing. 288 p.

Cooper, A. 2003. The origin of personas.

Cooper, A.; Reimann, R.; Cronin, D. 2007. About face 3: the essentials of interaction design. Wiley. 648 p.

Goodwin, K. 2001. Perfecting your personas.

Goodwin, K. 2002. Getting from research to personas: harnessing the power of data.

Goodwin, K. 2006. Taking personas too far.

Goodwin, K. 2009. Designing for the digital age: how to create human-centered products and services. Wiley Publishing, Inc., Indianapolis, IN. 739 p., including index.

Hart, G.J. 1996. The five W’s: an old tool for the new task of audience analysis. Technical Communication 43(2):139–145.

Hart, G. 2002. The five W’s of online help.

Noessel, C. 2006. Ignore that designer behind the persona.

Schriver, K. 1996. Dynamics in document design: creating text for readers. Wiley. 592 p.


Geoff Hart

13 years ago

Bruce Byfield notes (https://brucebyfield.wordpress.com/2011/09/10/why-personae-are-a-waste-of-time-in-technical-writing/): “I haven’t written a manual for over seven years, so perhaps my opinions about technical writing don’t count for anything.”

Far too easy, so I’ll let that one pass. The important point in this article and in your blog post is the following statement you made: “Admittedly, the exercise of creating a persona can help a writer fix audience segments in mind.”

That’s the whole point of my article: a great many technical writers, including many with years of experience, don’t make even a token effort to do this. They assume that audiences are monolithic and irrelevant so long as they do a good job describing the interface. As a result, they produce the kind of crappy documentation that does a perfect job of describing the product, but is completely useless to anyone who doesn’t already know the product. (Are you listening Adobe and Microsoft?) This is the main reason why publishers such as O’Reilly get rich publishing large series of third-party manuals for commercial software.

Bruce notes: “My impression is that personae are favored by those who stress the writing in their job title at the expense of the technical.”

Very true, because writing = communication, and technical = the product. Writers who remember that the goal is communication still write; those who think it’s all about the technology don’t care about the audience, and are more focused on their own technical needs. Which do you think produces better documentation?

Bruce then provides statistics [sic]: “Nine times out of ten, however, such efforts fail, because they are usually made at the expense of actually learning the subject matter, and of writing and editing.”

90%? Oh really? Let’s see your statistics: name the 10 projects you are considering in this analysis, and tell me which of them worked, and how it differed from the other 9. Or is this merely cherished notion masquerading as fact?

Bruce: “The result? You’re left looking pretentious and turn in a finished manual that only reinforces everybody’s impression that you are a lightweight poseur.”

The only data I have completely contradicts this notion. I’ve written manuals for half a dozen products (MultiDat software and hardware manuals, Harvesting and Silviculture decision support tools, GPS tool, and an in-house document tracking system) using the basic principles behind personas. I succeeded in each case because I understood who I was writing for. The manuals were very well received; for the first four products, the corporate trainers came to personally thank me for what I’d done because the docs cut their efforts to a fraction of the former level—because the manuals met the needs of their audience. Can’t speak to the last two, since I was gone by the time they were implemented.

It’s important to note that I never wrote a Batman persona description. I chose that example specifically because every time I use it in teaching, I can see the light go on in the minds of the audience. An effective persona focuses you on what’s important. An ineffective persona focuses you on a trivial exercise in creative writing. Understand the difference?

Personas and the five W's: Meeting Reader Needs, Pt. 2 | Tech Writer Today Magazine by TechWhirl

13 years ago

[…] the first part of this article, I introduced the concept of personas, a tool for creating a detailed description of […]

Why personae are a waste of time in technical-writing « Off the Wall

13 years ago

[…] count for anything. All the same, I’m disappointed to see that writers are still being steered towards distractions such as writing personae I can think of little that could do more to waste a writer’s limited time or cause them to be […]

Subscribe to TechWhirl via Email