Ad-Hoc Personas & Empathetic Focus

AD-HOC PERSONAS and Empathetic Focus
(revised 16 Nov. 2004)

John Pruitt and Tamara Adlin are writing a book on the use of "Personas" in design. They asked if I would write a sidebar to be inserted into the relevant chapter of their book: here it is, but with additional notes and discussion.

To be printed in Pruitt, J, & Adlin, T, "The Persona Lifecycle: Keeping people in mind during product design."San Francisco: Morgan Kaufmann Press.

Defining Personas

A Persona is an artificial person, invented for the purpose of helping a designer understand the people who will be using their product. Personas have been used for a long time. When I joined Apple Computer in 1993, Joy Mountford and her group were using them, although not under that name. Pruitt and Adlin have traced their heritage to much earlier. But to the modern design community, their usage was popularized by Alan Cooper in 1998 in his book "The Inmates Are Running the Asylum."

Personas as a Communication Tool

Design is in many ways an act of communication (see my essay, Design as Communication), but in order to communicate effectively, the designer must have a clear cohesive, understandable image of the product being designed and the user of the product must be able to understand that communication. Personas, by emphasizing the several different kinds of unique individuals who will be using the product, aid the designer in maintaining focus, concentrating on design aspects that the individual Personas need and eliminating from the design things they will find superfluous. So to me, the Persona is a tool for focus and an aid to communication, and for this purpose they only need to be realistic, not real, not necessarily even accurate (as long as they accurately characterize the user base). Although it is often fun to read the detailed descriptions of Personas and to pry into their private and social lives, I have never understood how these personal details actually aid in the design process itself. They seem completely superfluous.

Thus, a major virtue of Personas is the establishment of empathy and understanding of the individuals who use the product. It is important that each Persona seems real, allowing the designer to ask, "how would Mary respond to this?" or Peter, or Bashinka?

As I was writing this essay, I discussed it with John Pruitt and Tamara Adlin. Adlin pointed out that Personas also play an important communicative role within the design community and within the company producing the product. When one discussed the product in terms of its impact upon the individual Personas, the language of the discussion is automatically based on that of the people who use it and the benefits (or difficulties) that would accrue to them. This is in contrast to the technical language that is so often applied when talking about the features and attributes of the product: Personas makes it easier to be human-centered. "It gives a common language around experience," said Adlin, "so designers, engineers, and marketing people can all share a common language when they talk about the product." The same tool is valuable when the product is being designed by different groups within the company -- and this is always the case with any large, complex product. The use of Personas helps standardize the approach of each group, so there is continuity of level and function in the different parts of the product.

Empathetic Focus

The purpose of the Persona, I believe, is to add empathetic focus to the design. Empathetic focus. By focus I mean that the design must be clean and coherent. It is not a collection of features added willy-nilly through the life-span of the product, even if each feature by itself makes sense. Rather it is having a clear image of what the product is meant to be -- and what it is not meant to be -- and rejecting features that do not fit, only accepting ones that do. By empathy, I mean an understanding of and identification with the user population, the better to ensure that they will be able to take advantage of the product, to use it readily and easily -- not with frustration but with pleasure.

Using Ad-Hoc Personas

As a consultant to companies, I often find myself having to make my points quickly -- quite often in only a few hours. This short duration makes it impossible to have any serious attempt to gather data or use real observations. Instead, I have found that people can often mine their own extensive experiences to create effective Personas that bring home design points strongly and effectively.

In one case, for a major software company, one of their major customer bases was American college students. We quickly identified several different classes of students:

* Case one: A student attending a two-year community college while holding a full-time job;

* Case two: A student in a four-year institution who wanted to have a successful business career;

* Case three: A student who was only in school for lack of anything else to do, who had no desires except to have a good time.

We quickly invented one relevant Persona per case: a hard-working, single mother (case one), a serious full-time student with no outside experience or responsibilities (case two), and a lackadaisical, laid-back goof-off (for three). Unlike traditional Persona studies, these were all made-up, but each was described in sufficient detail (including names), so that the group all agreed they felt like people they knew.

I have found that an excellent way to use a Persona is to have someone role-play the part. In this way, only one person has to develop an in-depth knowledge of the Persona, and everyone else uses the role-player as an expert informant, doing participatory design, where the user is the person doing the role-playing.

In this case, I divided the attendees at my workshop into three groups to do a design exercise, with the person role-playing the relevant Persona to be their expert "informant." The result was wonderful to behold. The teams all produced highly user-centered designs, all very different in kind and in spirit from the products of their company, even though some of the designers of those products were in the workshop. The differences were striking,. The case three student kept saying "I don't care" when asked about choices, while simultaneously making it clear that he wanted a system that required no effort or thought on his part, but that gave him his preferred outcome (receiving a degree, but with minimal impairment to his preferred life style). The case one and two students were more active, more involved, but because of their different requirements, imposed different demands upon the software.

Everyone agreed that this simple exercise had altered their perspective on what a product ought to do and how they should approach design.

Another consulting job was for a major publisher of city-information products. This group of attendees consisted of the executive team for the company, so although none of them actually designed products, the product groups were all under their control. For this workshop, I had the group invent two couples. One couple was young, newly married and about to have their first child. They had only a small apartment and did not have much money. Their task was to use the city guide to find a crib for the expected child. The other couple was older, retired, and with significant discretionary income. All their children were away from home, living independently. My original intention was to have this older couple book a travel adventure, but because we were running out of time, I switched the exercise: I announced that the older couple were the parents of the expectant mother, and they wanted to buy a crib for their new grandchild.

The new exercise was extremely rewarding because it demonstrated how the two couples approached the task very differently, with different emphases, different search characteristics, and very different values. Having the workshop attendees work on the same problem was serendipitous, for it revealed the deficiencies in the existing city guide. Interestingly enough, after the conclusion of the exercise, several of the executives admitted that their own behavior mimicked that of the older couple, including the observation that they seldom turned to their own city guide as a first step. This sensitized them to the fact that their own behavior with their company's product was a relevant datum -- "realize that others might behave the same way you do," I admonished them, "take your own behavior seriously."

(Parenthetical note. A more accurate rule to designers is this: If you do not want to use your own product, or if you have difficulties using it, take this seriously. After all, if you have problems, how will the average user manage? But, if you have no difficulties, do not take this as legitimate data. After all, you designed it -- you shouldn't have any problems. The fact that you have no difficulty tells you nothing about the behavior of the average user.)

The Final Assessment

These two different examples of Personas are very different from the traditional usage of the concept. They are created quickly, they do not use real data, and they are employed without much background information and attention to detail. But even so, they serve as wonderful tools for building understanding and empathy into the design process in a way that would be impossible with any other method.

Do Personas have to be accurate? Do they require a large body of research? Not always, I conclude. The Personas must indeed reflect the target group for the design team, but for some purposes, that is sufficient. A Persona allows designers to bring their own life-long experience to bear on the problem, and because each Persona is a realistic individual person, the designers can focus upon features, behaviors, and expectations appropriate for this individual, allowing the designer to screen off from consideration all those other wonderful ideas they may have. If the other ideas are as useful and valuable as they might seem, the designer's challenge is to either create a scenario for the existing Persona where they makes sense, or to invent a new Persona where it is appropriate and then to justify inclusion of this new Persona by making the business case argument that the new Persona does indeed represent an important target population for the product.