Extending a Technique: Group Personas

Spock: “The needs of the many outweigh the needs of the few.”

Kirk: “Or the one.”

–Star Trek II: Wrath of Khan

I recently had the pleasure of teaching a workshop on applying user-centered design methods to personal technology design in a European amusement park.

The workshop started out typically. We interviewed company management, mapped out the goals of the company, the context in which the project was being done and collected information about how people currently behaved in the park. We then identified several classes of users, created personas for them, and started creating scenarios using these personas.

Initially, the workshop progressed about as it would if we were going to be designing a piece of desktop software or a website, but the minute we started developing personas and scenarios, the unique nature of the park started to become clear. We first sketched out some personas, and that went fine. But once we began working with scenarios for a while, trying to create believable situations for these characters to behave in, we noticed something: all of our scenarios consisted of groups of personas interacting with the environment or with other groups of personas. That’s when we realized that individuals mostly don’t act alone in amusement parks. People rarely go alone and they don’t make decisions alone. Needs and desires are negotiated in a group, not expressed individually. People really fully embrace the experience only when they’re experiencing it with others. In this environment, individual personas and scenarios for them matter less than what happens to groups of people.

So we decided to see if we could make group personas. At first, there was some apprehension–what if the groups are so varied as to be impossible to characterize? But as soon as we started making them, only several different kinds of personas made sense and it became a straightforward extension of Alan Cooper’s original persona technique. Here’s how we did it.

Individual descriptions

We had started by describing individual personas, so we had the building blocks of groups, and we used those personas as the basis of our subsequent work. Those personas were based on several visitor categories that we defined based on the park’s operators’ knowledge of their audience–the statistics they had and their personal experience with the park:

• Teenagers
• Young adults
• Pre-teens
• Young parents
• Grandparents

We decided to leave the profiles broad, rather than going into detailed persona building, and described each group along some criteria appropriate to the problems the park was trying to solve. Young parents, for example were described thus:

• Age: 25-35
• Children: 2
• Budget: $75-100 per day (in the park, not including tickets) per parent
• Technology: cell phone (6-24 months old), digital camera, video camera, computer at home, internet connectivity in the office
• Desires: have fun with kids, let kids run around in safe place
• Needs: to have fun, too; place to change diapers; place to sit down; to buy food/drink

Of course, this only scratches the surface of how young parents in an amusement park can be described–we could have defined different criteria based on gender, culture (this park has sizable populations of visitors from as far as Poland), etc.–but time was limited and it was enough to get us started creating group personas.

Rough outlines

Before fleshing out the group personas, we decided to make some rough outlines of the clusters of people one might find in the park. Based on what we had heard from the park staff and additional interviews we conducted with a couple of friends-of-friends who had visited the park as tourists, we came up with four different groups to focus on, and tried to give them distinctive names:

• The Teen Posse
• Young Parents, Young Kids
• The Extended Family
• College-age Friends

We also defined some axes along which we could define the group. Again, we chose to pick out those qualities that we felt would be valuable in answering the park’s questions, rather than trying to describe every detail. Thus, the “Young Parents, Young Kids” general description looked like this:

• Number of people in group: 5
• People in group: 2 adults, 2 kids ages 3-10, grandparent
• Time spent in park per day: 6 hours
• Number of days visiting park: 2
• Season: August

The level of detail at this stage needed to emphasize the group as a whole and make it different from the other groups, without burdening it (and ourselves) with descriptions that didn’t affect the end experience. We didn’t describe the individual members of the group, and included as few constraining specifics as possible. Such details and idiosyncrasies would come in the persona, which we did next.

Iterative persona creation
We developed each persona in several passes, both to refine the persona until it had sufficient believability and because this was the first time any of us had developed group personas, so we naturally ended up over-describing certain aspects and under-describing others. The process was roughly as follows:

• a rough sketch, where we quickly outlined the persona, determining its composition and adding some defining details
• a detail brainstorm, where we added as many details as we could, even if they were silly, contradictory or redundant
• editing, where we cut out everything we thought was irrelevant to addressing the project focus, and clarified overlapping ideas
• preliminary scenario writing, during which we “exercised” the personas by walking them through some examples in which they interacted with the park and some of the design ideas on the table
• tuning, where we adjusted the personas based on what we had learned from the scenarios

After a couple of days of doing this for 2-3 hours per group persona, we had four fleshed-out group personas and some scenarios that we felt were typical examples of groups who visited the park and how they would behave. These we used to examine the problems the park was experiencing and our proposed solutions.

Example: The Ancona Family, a secondary persona
Note: this persona is significantly modified from what we developed in the workshop.

Back story
Luisa and Giorgio, a couple in their mid-30s, have decided that the family needs a vacation. It’s mid-August and they’re spending time with Luisa’s parents, Maria and Carlo, at their home outside of Rome. Mauricio and Laura, their children, are getting bored and cranky and clearly need a break from hanging out at the grandparents’ house. Giorgio suggests they spend a weekend at an amusement park with water rides before they go to Rimini for the traditional week on the beach. Maria, Luisa’s mother, will come along. She’s always willing to help out with the kids.

Demographics
Luisa and Giorgio are in their mid-30s. They live in Rome. They’ve been married for five years. Giorgio is a mechanical engineer and Luisa is a full-time parent and also works part-time at her parents’ grocery store.

Mauricio and Laura are their 7- and 4-year-old children.

Maria is Luisa’s mother. She is in her late 50s. She lives outside of Rome with her husband, Carlo. They own a small grocery store, where Maria manages, in addition to being a full-time homemaker.

Technology use
The park was interested in developing wearable or portable technology for people to use as they’re being entertained, so we included a range of technologies in our description, rather than just focusing on computer and software experience, as we would have if this was a piece of software or a website.

Luisa and Giorgio have mobile phones. They’re very comfortable sending text messages, and typically send 3-5 to each other per day. Luisa sometimes uses hers to play video games and she texts one of her friends almost every day. Luisa’s phone is newer than Giorgio’s and has a camera.

They have a two-year-old computer at home, which Giorgio and Luisa use to send email (they have a dialup internet account) and which the kids use to play video games and watch DVDs.

Giorgio has a faster internet connection at his office.

They have a digital video camera with them, which Luisa bought for Giorgio for his last birthday.

Maria doesn’t have a mobile phone, but she’s comfortable using one.

Luisa and Giorgio have taught Mauricio how to call the emergency number on a mobile phone, but he’s otherwise not used one even though he understands in principle how they work.

Goals
Group goals are a negotiated combination of individual goals. In a family trip, most of the long-term goals are set by the parents, and most of the short-term goals are set by the kids.

Mauricio has one major goal: to ride the big roller coaster over and over again. He’s never been on one, but he knows about it. He’s also very interested in the dinosaur area.

Laura has never been to an amusement park before, so she doesn’t know what to expect, but her parents told her about the costumed mascots and water rides and she’s excited to see those.

Giorgio:

• Have fun with his kids
• Wants to use his new video camera
• Wants to ride the roller coaster

Luisa:

• Wants to spend time with Giorgio and her kids
• Wants to ride the ferris wheel

Maria:

• Talk to her daughter
• Spend time with her grandchildren

Combining these, we get a set of general goals:

• Ride the big roller coaster
• Avoid boredom
• Spend time together

Needs
In our example, goals are individual but they affect the whole group, whereas needs are mostly group-wide. This may be a product of our process, or it may point to a general case of how group personas work.

• Find each other
• Find the bathroom
• Be entertained while waiting in line
• Get food/water
• Rest for Maria, while kids are being entertained

Purchasing profile
Since selling stuff is a key amusement park revenue stream, we decided to do a short profile of what the group is likely to purchase throughout the day.

• Ice cream, bought by Maria, as a treat for the kids
• Soda in a theme cup, requested by Laura, bought by Giorgio
• Lunch for everyone, bought by Luisa and Giorgio
• Disposable camera bought by Luisa
• Sunscreen, bought by Luisa
• T-shirts for Mauricio and Laura, bought by Giorgio

Example: Ancona family scenarios
Having developed a general group persona, the next step was to develop some scenarios using the persona in order to test it and further refine it.

Day narrative
We began with a general narrative of what happens during the day. Here’s an abbreviated version of the first day:

6:00 AM: kids wake up
8:00 AM: breakfast at Maria and Carlo’s home
9:00 AM: family leaves for park
10:30 AM: arrive at hotel near park, check in
11:30 AM: leave for park
12:00 PM: arrive at park, buy tickets, go in, start getting oriented
12:30 PM: orientation chaos: where to go? what to do? Negotiation and prioritization.
12:45 PM: Giorgio and Mauricio head for roller coaster. Luisa, Laura and Maria start looking for a place where Maria can wait with Laura while Luisa joins her husband and son.
1:00 PM: Giorgio and Mauricio arrive, get in line.
1:15 PM: Luisa and Maria find picnic area where Maria can wait.
1:30 PM: Luisa joins Giorgio and Mauricio.
2:30 PM: Luisa, Giorgio and Mauricio get to the front of the line and ride the roller coaster. Everyone is very hungry.
2:45 PM: Group reunited, start looking for lunch.
3:00 PM: Lunch bought at stand near picnic area.
Etc.

Where are Giorgio and Laura?
Using this structure, we started thinking about technological solutions: what problems are encountered? How can the information technology we know the family has or has experience with affect the situation? How can the park benefit?

Business problem:
People complain of getting lost when trying to reunite when groups separate.

Scenario:
Laura really wanted to go on the water flume ride, but since everyone gets soaked while on it, the rest of the family doesn’t really want to go. Giorgio and Luisa agree that he’ll go, while she and Mauricio and Maria go to the ferris wheel. Since everyone gets soaked, Giorgio doesn’t want to take his mobile phone and leaves it with Luisa. Now, how will they meet up again? They don’t know how long the lines at the various rides are. How will they know when to meet? If the water ride line is as long as the roller coaster and the ferris wheel has no line, then Luisa, Maria and Mauricio may end up waiting hours for Giorgio and Laura to get back.

Potential solutions:

• Wait-time kiosks. If there are kiosks scattered around the park that tell people how long the lines at the rides are, then the family can estimate how long the whole process will take and pick a time and place to meet up again.
• RFID bracelets/ride check-in. Everyone gets a wrist bracelet when they buy their ticket. Assume that each bracelet has an RFID (radio frequency ID) tag in it and people’s IDs are linked
• Waterproof mobile phone bags. Watertight bags provided by the park for people waiting in line for water rides. These allow people to coordinate and communicate using the tools they’re familiar with.

Using the group persona, we were able to explore and evaluate how well these solutions worked, both for the Anconas and for the park. The low-tech solution, the bags, is cheap and requires the minimum investment by the park in new technology and by the Anconas in learning a new system, but it’s not without problems. What if Giorgio, who’s quite attached to his phone, doesn’t trust the bag?

What we learned

This exercise was incredibly helpful when we started designing technology to support people’s experience in the park.

Groups are not individuals, though they sometimes act like them.

As the persona is developed and as scenarios are written, the focus shifts from the individuals in a group to the group as a whole. The group is rarely treated as an entity identical to an individual, but it often behaves as one. So when the Anconas move around the park, they’re often moving as a group. Where they go may be heavily influenced by one person’s desires (Mauricio’s desire to ride the big coaster), but the decision is made collectively and they act as a group.

Group descriptions should have moderate detail, but not too much.

While it’s not necessary to describe either the group or its members in deep detail, some description is important. In fact, describing groups as groups is actually tough: we just don’t have that many axes along which we typically describe small groups: we can number the members and collect aggregate demographic information, but that’s about it. We had to invent a lot of the categories we used on the fly.

The design goal drives the persona description.

Remembering that this was an amusement park and that we were going to be designing ways in which the park could support and encourage the use of personal technology really helped focus the persona development process. It narrowed the directions we explored and how we spent our time fleshing out ideas. There were times when we’d go too far into describing the persona and clearly enjoying the storytelling aspect too much, which was fine and often useful, but then the design goal allowed us to edit what we had produced so that it was most relevant.

Imperfection is important.

We found we had a tendency to tell stories where everything goes right and technology saves the day and makes everyone happy. Though this made us feel good, it’s not realistic, and the exercise of examining where our ideas could fail, where they could be misunderstood and misused, was quite helpful.

This is a really useful tool for realistic idea generation.

When given a broad mandate, this technique allowed us to narrow the space of all possible uses of technology from what was merely possible to what seemed like it would be actually useful and valuable. It defined the space in which we could create innovative ideas and to understand where services that bridged technologies made sense and where they didn’t. It also allowed us to see the problems with some of the ideas.

Extending traditional techniques to groups is possible and valuable.

This was the first time I tried this technique. Frankly, I kind of invented it on the spot and my workshop participants ran with it, but the process of taking a known technique and stretching it to a new set of problems proved quite valuable, both in terms of helping us solve the problems we were tasked with and in terms of understanding what I know about individual personas.

Extending to other kinds of experience design.

So what does all of this amusement park stuff have to do with software and websites? It’s directly applicable to software that’s used by groups. Entertainment, education, and collaboration software is often used by two or more people simultaneously (and not in the sequential “I edit this, then I give it to you to edit” model, but simultaneously). It’s difficult to imagine teleconferencing software without thinking about two groups—one at either end of the connection—using it; sometimes these are groups of executives, sometimes they’re technical collaborators, sometimes they’re mixed. Each of these different groups has a different set of needs and expectations from the software, and each can be modeled as a group persona, rather than as individual users.

In the most general sense, as our tools become more social, as information processing and ubiquitous computing pervade our environment, so should our techniques to model their users. Group personas are a small and easy step.

Bibliography

Cooper, Alan. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore the Sanity. Indianapolis, IN: Macmillan, 1999.

Cooper, Alan, et al, Newsletters on Personas.

Kuniavsky, Mike. Observing the User Experience: a Practitioner’s Guide to User Research. San Francisco, CA: Morgan Kaufmann, 2004.

Olsen, George, Persona Toolkit (.pdf), February, 2004.

Disney Trip Report Archive, 27 July, 2004.

Mike Kuniavsky is the author of Observing the User Experience: A
Practitioner’s Guide to User Research (Morgan Kaufmann), and has been
developing commercial websites since 1994. He is a founding partner of
Adaptive Path, one of the world’s premier user experience consulting
companies. Previous to co-founding Adaptive Path, Mike was the
interaction designer of HotBot, the award-winning search engine, and
creator of the Wired User Experience Laboratory, where he served as chief
investigator.

He is currently an independent consultant, focused on ubiquitous
computing and on the ways that such technology changes everyday objects
and experiences. His blog is www.orangecone.com.