Sketches of people in action poses, by Uday Gajendar

It’s hard to write any article about personas — the design artifact people love to hate — without a string of caveats. But, here I am, writing about personas with no caveats. Let’s do it.

With the Rapid Personas play I’m trying to address a couple of challenges in the design process:

Rapid Personas are not definitive. They’re not comprehensive. Instead, they elevate some interesting aspects of the product’s target audience. As an activity, the Rapid Personas play serves as a prologue to other brainstorming activities. Rapid Personas prime participants in your brainstorming activities to keep user needs top-of-mind as they imagine new ideas and concepts.

In this activity, participants construct one-sentence mad-lib-style personas by selecting a role, a need, and a challenge from a limited list of options. You’ll end up with things like:

Yes, I realize these aren’t complete personas. Don’t @ me.

The activity works because participants have a narrow set of choices for each role, need, and challenge. Even if you only have three choices for each slot, that’s 27 possible combinations. Because the options are limited, they have to read and consider each one.

The key to making this exercise work is that the roles and needs and challenges have to be independent of each other. That is, a need can’t be tied to a specific role and a challenge can’t be tied to a specific need. The way to make this work is to link them to different aspects of the user’s experience.

In a brainstorming session for a learning app, I used roles that were related to the person’s reason for learning: naturally curious, studying for an exam, or earning credits. Distinct from the reason, the need represented the scope of what they were learning: to brush up on an old topic, to learn a new topic, or to study a topic assigned to them. Finally, the challenge reflected the typo of pressure they were under, regardless of their reason or objective: they were short on time or they had never used the learning app before. These combinations worked because the options themselves are independent of each other.

For a project about marketing a technology product, the Rapid Personas broke down this way:

The technology product we were dealing with addresses people’s needs throughout the organization. People in different positions might deal with different kinds of digital assets, but they all have a need to do so.

For me, this play works best after I’ve done some user research. Everyone carries assumptions into the design process, and user research can shake those up. Research has helped me:

As you describe each role, need, and challenge, providing some rationale for why you chose these can make or break the play. One way participants might undermine the exercise is to call into question the validity of the options. By responding with observations from user interviews, you can re-direct the conversation to where these differing views come from.

Remember: this activity won’t tell you anything about your users. It does tell you a lot about the people working on your project. Look at the roles, needs, and challenges they avoided to find out where they feel a lack of confidence. Look at the roles, needs, or challenges most selected to find out where they feel overconfident. Watch how they integrate these rapid personas into the rest of the workshop: do they ignore them? reinterpret them?

Clarifying for yourself and your team where the preconceptions and misconceptions are, and how deep they go, can help prioritize your research and discovery activities. It can also help you shape the narrative of your design efforts.

If you try the Rapid Personas play in a workshop, let me know how it goes. Comment here or hit me up on Twitter @brownorama.

In this activity the team will generate Rapid Personas by picking a role, a need, and a challenge.

Setting up other activities that require a user-centered focus. For example, before engaging stakeholders in a card sort, use ad hoc personas to get them in the right frame of mind.

An example workspace. Create one of these for each participant.

With fewer than 10 participants, you can go one-by-one to have them create their rapid personas.

Who goes first? When going around the table, the hardest part is figuring out who should go first. If I know I have a “ringer” — someone who gets the activity and can articulate their choices well — I ask them to go first. I’m looking for someone who can set the tone for the rest of the table.

With 10 or more participants, going around the table can be unwieldy and time-consuming. You can make these changes with a larger group.

In place of step 5 above (going around the table) I instead give everyone 3 minutes to select a role, need, and challenge.

In place of steps 6 and 7 above, I instead ask, “Does anyone want to share the persona you came up with?” I’ll call on two or three people to share their rapid persona. After they recite the persona aloud, I’ll ask, “What made this hard?” or “Why did you gravitate toward those choices?”

👓 Dan Brown has been practicing user experience design for over 25 years. He co-founded EightShapes, a Washington, DC-based user experience design firm. Dan wrote three books on user experience design, most recently Practical Design Discovery. He produces tools and games for design teams, including Information Architecture Lenses.

Need to run a workshop? Looking for some help with your product’s user experience, user research, or information architecture? Just want to chat? Let’s set up a time to talk! 🗓