Rapid Personas: a play for your UX Playbook

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:

1. Encouraging stakeholders to keep specific user needs top-of-mind during a brainstorming exercise
2. Encouraging stakeholders to let go of their misconceptions about their users

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:

I am a hiring manager who has to evaluate candidates for a position but I’m afraid of implicit bias.

I am a small business owner who has to define the requirements for a position but I’m afraid of implicit bias.

I am a recruiter who has to evaluate candidates for a position but I’m not clear on all the technical needs.

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.

Example 1: Learning App Rapid Personas

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.

Example 2: Tech Marketing Rapid Personas

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

• Role = position in the organization (team lead, contributor, executive)
• Need = tasks typical for products like this one (all related to managing digital assets)
• Challenge = problem typically associated with legacy solutions (e.g. security, decentralization, etc.)

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:

• Reframe roles based on how users refer to themselves, not how stakeholders refer to them
• Highlight high-priority needs
• Reveal challenges not previously acknowledged

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.

Summary

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

Objectives

• Encourage project stakeholders to adopt a user’s perspective when participating in design activities.
• Identify underlying biases in the stakeholder group.

At-A-Glance

• Workshop time: Up to 15 minutes
• Preparation time: Up to 1 hour
• Input: Requires user research to inform the selection of roles, needs, and challenges
• Number of participants: Best with 10 or fewer, but can accommodate more

Use When…

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.

Preparation (allow 1 hour)

• Create a list of 3–5 roles. Use labels that the users themselves would.
• Create a list of 3–5 needs. Each need should start with a verb. Write the needs so that they might be attached to any role.
• Create a list of 3–5 challenges. Once again, write these in the user’s own words, and make them applicable to any of the roles. They should be complete sentences.
• Finally, create a workspace with a mad lib-style space for each participant. The mad lib should take the form:

I am a [ROLE] who has to [NEED] but [CHALLENGE]

Method (allow up to 15 minutes)

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

1. Explain the purpose and method of the activity, providing an example of a possible output.
2. Ask someone to read aloud the list of roles. Explain that these roles might not be how the group typically thinks about their users. Ask the table: “Does anyone have any questions about these roles?”
3. Ask a different person to read aloud the list of needs. Ask the table: “Does anyone have any questions about these needs?”
4. Ask another person to read aloud the list of challenges. Ask the table: “Does anyone have any questions about these challenges?”
5. Go around the table. Direct each person to pick a role, need, and challenge. Have that person read their mad-lib rapid persona out loud. Go on to the next person.
6. When everyone has set up their persona, ask if anyone would like to change anything about their persona.
7. Ask the table: “What made this hard?” and see if anyone would like to share their worries or concerns during the activity.
8. Remind everyone to keep their persona in mind as they move on to the next activity.

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.

Alternative: Larger Group

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?”