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

Part II: Applying the five W’s

In the first part of this article, I introduced the concept of personas, a tool for creating a detailed description of the people we’re writing for. An ideal persona becomes so real that we intimately understand who that person is, what their needs are, the problems they face—and therefore, what we must do to help them solve those problems. To make that admittedly somewhat abstract more concrete, I used the example of Bruce Wayne—the man behind Batman’s mask—because of how instantly familiar that persona is to most Westerners. That description, simplified as it was, provides a strong hook on which to hang more details. Bruce is the answer to the “who?” question, the first of the five W’s. In this concluding part of the article, I’ll show how answering the final four questions (when, where, why, and what) provides the insights we need to create effective documentation.

“When” and “where” for Bruce: context

Now that we know who Bruce is, let’s explore his context. Bruce faces dangerous enemies who, despite their well-understood personas, are difficult to predict. Moreover, he’s doing this behind the wheel of a complex vehicle during high-speed chases through a complex and unpredictable urban environment. Problems associated with this context include the vehicle’s high speed (which requires near-instantaneous decisions), with frequent hard acceleration and deceleration, many sudden direction changes, and the appearance of many obstacles, only some of which can be anticipated. The task of predicting the behavior of human foes and the Batmobile itself in time to respond appropriately requires human cognition, since these factors are too complex to predict using computers alone and since the environment is outside Bruce’s control. Instead, computers must assist Bruce in using the Batmobile so he can turn his brain to the more difficult task of understanding what his foes will do and how he should respond. These decisions will occur (predominantly) at night, which means that the work environment will be dark, making vision more difficult. On the plus side, there is less vehicle traffic to interfere with his actions than would be the case during the day, and fewer pedestrians to protect.

For each persona, answering the “when” question involves understanding the situations that force the user to use the product and the supporting documentation, as well as the various obstacles posed by these situations. For Bruce, the context is one in which many things are happening simultaneously in a confusing environment with limited visibility. Bruce’s emotional context involves rapid decisionmaking under stress, possibly while trying to ignore the pain of a variety of injuries, and both factors interfere greatly with the ability to think clearly and quickly. On the plus side, Bruce is operating on an adrenaline high, so his reaction speed (already exceptional) will be further enhanced.

Similarly, answering the “where” question asks us to place ourselves in the persona’s situation (here, in the driver’s seat) and ask ourselves what that environment implies. For Bruce, the physical context is a complex external environment with many distractions, and very little available space: think of a cramped economy seat in a commercial aircraft, not the first class section. Bruce’s emotional context is also important: he’s under an enormous amount of stress, what with impossible deadlines and serious (possibly fatal) consequences for any errors, creating a significant barrier to clear and correct thought. Unlike in most professions, Bruce mostly works alone and has few colleagues he can consult to ask for advice—thereby eliminating the most common source for finding information when the documentation fails. On the plus side, we know that Bruce and others like him have a superior intellect and superior reflexes (think of him as the proverbial “power user”), so we can focus on helping them to create an environment tailored to maximize the use of these assets.

Under these circumstances, there are two important contexts for using our documentation: “offline”, when Bruce can install new toys and configure the Batmobile at his leisure, and “in-use”, when he is actively using the Batmobile. In the former context, our goal is to provide guidance in configuring the product so that when Bruce is working in the latter context, he won’t have to open and read online help or a printed manual; indeed, he won’t have a free hand to flip pages, a help browser would be a dangerous distraction, and he won’t have enough time or mental resources for extended reading. This means that the majority of the information we provide must be embedded in the interface itself. Thus, our goal is to help designers streamline the user interface as much as possible and to design affordances (built-in clues to how a feature must be used) that eliminate, as much as possible, the need to consult external documentation or ponder what to do. In short, we must help the engineers prioritize functions.

Understanding Bruce’s working context so well, we can also provide insights into what default settings are most likely to be useful, what secondary settings are most likely to be useful when those primary settings won’t work, and so on. In short, we must help the engineers create useful defaults and teach Bruce ways to modify those defaults quickly and effectively. Similarly, we understand the likely sequence of actions required in a given context, and can design hierarchical menus that support those sequences. Any in-use information that we provide must be highly concise, possibly even telegraphic or graphical, because the time available for reading is minimal and we can’t afford to take Bruce “out of the task” (driving without killing himself or anyone else); this also suggests that we must teach him to create shortcuts for frequently performed tasks well before the tasks must be performed.

The need for shortcuts leads us back to offline documentation. This is documentation Bruce can use when he’s not actually chasing criminals, but is instead preparing to chase criminals at some future date. Consideration of the personas of Bruce and other potential users of the Batmobile should reveal the most common tasks that require shortcuts, and we can either provide those shortcuts along with the product, or include them in a comprehensive list of tasks Bruce should perform before he ever gets behind the wheel. Because Bruce has nobody to teach him how to use the Batmobile, and the limited market for such products means that its developers probably can’t afford to provide 24/7 technical support, the documentation must be comprehensive, and must bring him up to speed fast. Moreover, it must teach him enough about the plumbing and the interface metaphor that he can explore and find his own solutions.

Interestingly, Bruce himself may be a great source of knowledge that can be used to provide documentation for other personas, such as his sidekick Robin; Robin has less experience than Batman, and must thus be given additional support to learn the tasks Batman already knows how to accomplish.

“Why” and “what” for Bruce: tasks and details

Our next step is to think about the “why” and “what” questions, thereby revealing what tasks Bruce performs and why he performs them. This analysis identifies the tasks we must document and provides insights into how we should describe those tasks. Typical tasks for Bruce might be to pursue enemies (with the goal of catching them) and to evade enemies (so he can survive to fight another day). In both cases, it is crucial that he avoid harming civilians, important (but less crucial) that he avoid damaging public property, and helpful but not essential that the Batmobile survive the chase; after all, Bruce is rich enough that he can afford to build or buy a replacement if he crashes the Batmobile, but he can’t replace any wounded or killed pedestrians. His primary goal is therefore to catch or evade the bad guys while protecting the public. Key tasks required to support pursuit and escape include navigation and vehicle control during high-speed chases, as well as using the Batmobile’s built-in weaponry while defending against the weaponry of his opponents. Key constraints include the need to make decisions whose adverse consequences will be acceptable: a wrecked vehicle or damaged buildings, but never an injured civilian.

In this context, the Batmobile’s systems must be configurable in such a way that Bruce won’t have to perform the configuration on the fly and in a way that minimizes the burden on his mental resources: we must teach him how to set up the Batmobile so that once he makes a decision in the driver’s seat, its computers will handle the rest of the process and free Bruce to concentrate on the next problem and the big picture. Thus, we must document how to create preset responses to common problems (e.g., to ignore bullets because the Batmobile is bulletproof but to evade rockets because it’s not invulnerable to large explosions). Once in the driver’s seat, Bruce doesn’t have time to configure these actions, so we must instead empower him to choose quickly among preprogrammed alternatives that will respond on his behalf. For example, we should describe how to program the navigation system to automatically calculate and display course options based on predefined decision criteria (e.g., avoiding crowds, accepting damage to the vehicle). Similarly, we should explain how to configure options such as dynamic stability control so the Batmobile will support Bruce’s own reflexes; sometimes he’ll want the Batmobile to be able to skid, despite antilock tires and stability control.

To support these kinds of tasks, our documentation should include information on the main types of threats that users of the Batmobile will face, the permissible response options (plus their pros and cons), strategies for facing multiple problems simultaneously (e.g., accepting a direct hit from an explosive missile instead of swerving and allowing the explosive to harm civilians), and the consequences of using each option (e.g., the possibility that the Batmobile will be destroyed). Once in the vehicle, Bruce has no time to make these kinds of decisions, so we must provide tools that let him make the decisions beforehand to the greatest extent possible. But we must also teach him how to override any default settings he’s created when the situation calls for flexibility.

Summary

Few of us will ever face this specific documentation challenge, though the example is not nearly so unrealistic as it might seem at first glance. For example, technical communicators who work in the defense or health industries or in civil aviation may be called on to support products that require decisions in equally stressful situations and with an equally high risk of serious consequences if a decision fails. Anyone who documents vehicle navigation systems must understand the problems faced by drivers who must pay more attention to pedestrians and other vehicles than to the user interface. And all of us face the problem of providing both offline documentation (e.g., configuring a product before it will be used under stress) and in-use documentation (affordances that might eliminate or reduce the need to consult online help).

My exploration of the Bruce persona reveals certain implications for using the persona approach in other situations and for other personas:

• It identified two crucial information types we must provide: offline and in-use information.
• It identified appropriate media for presenting our information: comprehensive printed or online documentation for product installation and configuration, versus information “embedded” within the user interface to support users who have no time to read the documentation.
• Some information that we create will probably resemble “wizards” that present options and guide users through a decision process, letting them make strategic decisions (what to do) and leave the tactical decisions (how to do it) to the product.
• The more we think about Bruce and his situation, the clearer the characteristics of the required information become: we must comprehensively support initial configuration, but in-use documentation must be concise and embedded in the product.
• The persona’s context lets us remind developers that the interface cannot be a traditional keyboard–mouse combination: a wiser choice would be voice input and output, combined with a heads-up display of some sort and far more sophisticated auditory feedback than the usual incomprehensible beeps and clicks.

Developing a limited number of personas focuses our efforts on the types of user who account for most of our audience. This lets us accurately characterize the physical and emotional characteristics of their context while using the product, and any obstacles to success or success factors that arise from the constraints and opportunities in that context. Understanding the tasks and their reasons provides insights into how the tasks will be performed, the goals that shape the performance of those tasks, and the documentation required to support users in accomplishing their goals.

Reality checks

How does the use of personas relate to other forms of audience analysis? In Dynamics in Document Design, Karen Schriver describes three main types of audience analysis: classification (collecting data to group readers into categories), intuition (imagining the reader and designing for that imaginary reader), and listening (actually working with readers to understand their needs). Clearly, personas come closest to intuition, but that approach has serious weaknesses. Most obviously, a purely intuitive persona is artificial, and may not resemble real audience members. Although it’s possible to create personas without ever meeting or talking to a product’s users, that should always be a last resort—something we only do when our employer expressly forbids us from talking to the audience (a surprisingly common complaint) or when there’s no time or other resources available to research these users.

When these constraints don’t exist, we should develop personas based on real-world information for real users of our products. This is where the classification approach becomes useful: it provides some hard data to support the intuitive approach. In addition, we must test those personas to ensure they are realistic (Schriver’s “listening” approach). We can obtain the information used for classification and make the contacts required to let us listen to our audience using a variety of resources:

• Actual product users or the target users for a new products identified by sales or marketing staff.
• The techniques of ethnographic inquiry (http://en.wikipedia.org/wiki/Ethnography) and other forms of audience analysis.
• Online communities (discussion groups, blogs, etc.) of people who use our product or related products.
• Consumer or profession-specific magazines, which often do a great job of identifying the priorities of real-world users in their product reviews.
• Trade shows or professional conferences.
• Technical support staff who help people to use our product or related products.
• Trainers who deal directly with the users, whether they’re employed by our company or working as freelancers.
• Research results published in journals or elsewhere (e.g., PhD theses, conference presentations).

Personas should be validated against the real-world users, since an invalid persona may be dangerously misleading. If we can identify these people early in the design process, we can explain our prototype personas and ask them whether we’ve achieved a good fit, or have misunderstood them or neglected certain key details of their context. Based on this initial reality check, we can revise the persona and create sample documentation that we can subsequently test to determine whether the persona is as effective as we hoped. STC’s Usability and User Experience SIG (http://www.stcsig.org/usability/) can provide good advice on how this kind of testing should be done.

The key point to remember is that personas are a tool you can use to provide insights into your audience and inform how you design and present information. Personas are not the only tool you should use to understand your audience, and must always be subjected to a reality check to ensure that they’re valid and useful. They must be combined with other tools such as ethnography and usability testing to ensure that they truly meet the needs of the audience. But personas offer something no other tool provides: a visceral understanding of the users of our products that makes it clear what we must do to meet their needs through our documentation.

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. <http://www.cooper.com/journal/2001/08/perfecting_your_personas.html>

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.